From ghc-devs at haskell.org Mon Sep 1 00:05:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 00:05:19 -0000 Subject: [GHC] #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB In-Reply-To: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> References: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> Message-ID: <057.33459300af4c72dadcaed1ac8675273a@haskell.org> #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: IEEE754 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): thanks! This is pretty great, I think some of the issues have been resolved in GHC head (wrt signum being wrong), but I'll take a look at trying to understand the rest. What GHC version and OS and flags did you use to run the program? (so i can try to reproduce this later?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 00:10:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 00:10:16 -0000 Subject: [GHC] #9530: min / max do not always return the other argument when one of the arguments is NaN In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.7585b0f28945971197a1663fb47a207a@haskell.org> #9530: min / max do not always return the other argument when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: 9276 Blocking: | Related Tickets: 9276 Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): read what I was saying earlier, we agree the current situation is not satisfactory (and I am working on a proposal to make it better). Interesting, the first version of the IEEE standard (the 1985 standard) doesn't seem to mention anything about min/max http://www.wellposed.com/standards-documents-cache/IEEE754-1985.pdf point being, the challenge is to choose a definition that "works the most" subject to floating point being what it is. And the current on e in ghc BASE is certainly confusing and odd, but that a direct consequence of Float/Double min/max using their ORD instance definition of compare to induce the min/max operations. Thus, we need to balance a few tricky concerns (and definitional consistency!) when changin min/max, because if nothing else, the current behavior is exactly that induced by the defintion of compare on floating point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 00:12:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 00:12:00 -0000 Subject: [GHC] #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB In-Reply-To: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> References: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> Message-ID: <057.a77a50076d1d866642586050c88ee422@haskell.org> #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: IEEE754 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): I ran this with 7.8.3, on OS X, no flags. (Well I tried with -fllvm too, but it gave identical results, presumably because much of this is just picking up a C library.) PS: I'm glad to see that Prof Kahn is still going strong with floating point arithmetic, the sender of the email to which you referred me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 00:23:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 00:23:34 -0000 Subject: [GHC] #9530: min / max do not always return the other argument when one of the arguments is NaN In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.73cede245ff1e8a7eff7afb538e83cee@haskell.org> #9530: min / max do not always return the other argument when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: 9276 Blocking: | Related Tickets: 9276 Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): ok, heres a cleaned up version of the 1985 spec http://www.wellposed.com/standards-documents- cache/ieee754-1985-cleanedup.pdf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 02:51:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 02:51:47 -0000 Subject: [GHC] #9355: scanr does not participate in stream fusion In-Reply-To: <045.78e20f25bbc7f21106375cbee9bcd2e6@haskell.org> References: <045.78e20f25bbc7f21106375cbee9bcd2e6@haskell.org> Message-ID: <060.37076f67b279cc67759e43a7b791b774@haskell.org> #9355: scanr does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch Comment: Unfortunately, `nofib` doesn't use `scanr` at all (and maybe nobody else does either). That said, the core looks very good in some small fusion tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 05:12:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 05:12:37 -0000 Subject: [GHC] #9356: scanl does not participate in stream fusion In-Reply-To: <045.ab578058deeca9329303e3b009a823aa@haskell.org> References: <045.ab578058deeca9329303e3b009a823aa@haskell.org> Message-ID: <060.1dde137f3b759e7ebc648054c32e464b@haskell.org> #9356: scanl does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): There is some kind of bad interaction that makes `sum . concat . inits $ [1..10000]` explode (use tons of RAM) when `inits` is written using a `scanl'` similar to this `scanl`. If this is affected, it may not be ready to go after all. I can fix the problem by breaking the pipeline between `concat` and `inits`; there also isn't a problem if I drop the `sum`. If I use `foldl' (+) 0` instead of `sum`, then it doesn't explode anymore, but it still allocates excessively and runs slowly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 06:09:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 06:09:00 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.90acb9e8125c4600ba05acd36bfc36fc@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => new Comment: I worked with Bertram Felgenhauer a bit tonight, and it looks like he's right; initsQ2 really is better. Unfortunately, it appears that the implementation of `scanl'` given here has the potential to blow things up for `initsQ2` when combined with `concat`. In particular, if I do {{{#!hs main = print $ sum $ concat $ initsQ2 [1..10000::Int] }}} then it uses up all my RAM and takes forever. Interrupting fusion between `initsQ2` and `[1..1000]` does not help at all, but interrupting it between `concat` and `initsQ2` seems to work. Removing the `sum` also prevents it from using all my RAM. If I replace `sum` with `foldl' (+) 0` then it runs in a small amount of RAM, but allocation is still very high and it's very slow. I'm still struggling to tease apart the interactions here. One thing that ''seems'' clear is that at its worst, it fails to recognize that it can treat the lazy `foldl` of `sum` as a strict `foldl'`, which is disastrous. But that's not the only thing going wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 07:57:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 07:57:10 -0000 Subject: [GHC] #9532: Expose new CLZ/CTZ primops via `Data.Bits` interface In-Reply-To: <042.f5f5d5287348b632b9971ccbf3356cd1@haskell.org> References: <042.f5f5d5287348b632b9971ccbf3356cd1@haskell.org> Message-ID: <057.ae4d8fd44bd9098beaa7759dcdce468d@haskell.org> #9532: Expose new CLZ/CTZ primops via `Data.Bits` interface -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Data.Bits Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9340 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D158 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"3241ac56d371220ed0b9522a86678678532f48bc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3241ac56d371220ed0b9522a86678678532f48bc" Remove incorrect property in docstring (re #9532) The property countLeadingZeros . negate = const 0 doesn't generally hold and it's not such a useful property to state, as it simply follows from "sign-bit == most-significant-bit" for FiniteBits types which use twos-complement representation for negative values, and even then it breaks down for 0... TLDR, remove thinko from documentation of `countLeadingZeros` }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 08:29:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 08:29:01 -0000 Subject: [GHC] #8825: ghc can't determine gcc version on ru_RU locale In-Reply-To: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> References: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> Message-ID: <060.5b39747c4ce9974684ce8162529ce694@haskell.org> #8825: ghc can't determine gcc version on ru_RU locale -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D185 | -------------------------------------+------------------------------------- Comment (by maeder): LANGUAGE=en works for me, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 09:44:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 09:44:20 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.9263bf0ecc41dace167f396f46e6988c@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Didn?t look at the core yet, but this might be a case of non-linear recursion where an arity analysis in insufficient to get good code for a left fold, see 5.1.1 in http://pp.ipd.kit.edu/uploads/publikationen/breitner14callarity.pdf. I can have a closer look later. Can you, with these examples, please always include one complete self-contained file? Otherwise there is a risk that I might be testing with the wrong version of inits/scanl'/whatever. I assume you are on GHC HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 10:19:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 10:19:18 -0000 Subject: [GHC] #9535: Remove max_bytes_used from haddock tests Message-ID: <046.b450aff06541c96c843901eaaf37ab41@haskell.org> #9535: Remove max_bytes_used from haddock tests -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Simon M says: ?I think we should probably remove the max_bytes_used limits for the Haddock tests.? (I plan to ?fix? this in the HIW contributors talk, so please do _not_ fix it just now :-)) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 12:12:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 12:12:03 -0000 Subject: [GHC] #9523: Typo in GHC Generics documentation In-Reply-To: <045.f6500f2e6e7dfb47345436a2e3e2ff3d@haskell.org> References: <045.f6500f2e6e7dfb47345436a2e3e2ff3d@haskell.org> Message-ID: <060.30edef19bfe7149d87707f44c4230b7a@haskell.org> #9523: Typo in GHC Generics documentation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): Yes, it's a typo. Thanks for the patch! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 12:53:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 12:53:13 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.c14bffdbb5ea0a9452c07dc829e85737@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D172 | -------------------------------------+------------------------------------- Comment (by simonmar): Is there a reason not to use two separate files for the two formats other than atomicity of updates? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 15:09:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 15:09:50 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.137c2fc1fdea66a0f229584e4540a735@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:22 nomeata]: > Didn?t look at the core yet, but this might be a case of non-linear recursion where an arity analysis in insufficient to get good code for a left fold, see 5.1.1 in http://pp.ipd.kit.edu/uploads/publikationen/breitner14callarity.pdf. > > I can have a closer look later. Can you, with these examples, please always include one complete self-contained file? Otherwise there is a risk that I might be testing with the wrong version of inits/scanl'/whatever. I assume you are on GHC HEAD? I've attached a complete, self-contained test case. As I mentioned in an email, you should keep a close eye on RAM usage or run this program with heap limits set if you don't want to crash your computer. If this is an arity analysis problem that's too hard to fix, we can work around it by writing `inits xs = don'tFuse . map toListQ . scanl' snocQ emptyQ` to ensure that `inits` doesn't fuse on the problematic (and, in fact, rather unimportant) side. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 17:00:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 17:00:17 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine (was: magic number mismatch when installing 32bit on 64bit machine) In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.5f6ce3754a842a7153f4a0bc4e5dbfb9@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * owner: => MikolajKonarski Old description: > This is basically the same problem as reported here: > > https://www.mail-archive.com/ghc-devs at haskell.org/msg04439.html > > I have empty .cabal and .ghc, no ghc in paths and I have old Ubuntu LTS > (12.04.4) so I was able to install ia32-libs and a few other libs > > I've downloaded > > http://www.haskell.org/ghc/dist/7.8.3/ghc-7.8.3-i386-unknown-linux- > deb7.tar.xz > > configured, and make install says: > > {{{ > Installing library in > /mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell98-2.0.0.3 > "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy > libraries/haskell2010 dist-install "strip" '' > '/mikolaj/env/7.8.3i386/local/src/ghc' > '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' > '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' 'v p > dyn' > Installing library in > /mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell2010-1.1.2.0 > "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" --force > --global-package-db > "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/package.conf.d" > update rts/dist/package.conf.install > Reading package info from "rts/dist/package.conf.install" ... done. > "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register > libraries/ghc-prim dist-install > "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc" > "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" > "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3" '' > '/mikolaj/env/7.8.3i386/local/src/ghc' > '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' > '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' NO > ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi > magic number mismatch: old/corrupt interface file? (wanted 33214052, got > 129742) > make[1]: *** [install_packages] Error 1 > make: *** [install] Error 2 > }}} New description: I'm compiling i386 binaries on amd64 linux and reporting problems and workarounds in this meta ticket. The very first problem I encounter is a magic number mismatch message. This is basically the same problem as reported here: https://www.mail-archive.com/ghc-devs at haskell.org/msg04439.html I have empty .cabal and .ghc, no ghc in paths and I have old Ubuntu LTS (12.04.4) so I was able to install ia32-libs and a few other libs I've downloaded http://www.haskell.org/ghc/dist/7.8.3/ghc-7.8.3-i386-unknown-linux- deb7.tar.xz configured, and make install says: {{{ Installing library in /mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell98-2.0.0.3 "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/haskell2010 dist-install "strip" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' 'v p dyn' Installing library in /mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell2010-1.1.2.0 "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" --force --global-package-db "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/package.conf.d" update rts/dist/package.conf.install Reading package info from "rts/dist/package.conf.install" ... done. "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register libraries/ghc-prim dist-install "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc" "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' NO ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) make[1]: *** [install_packages] Error 1 make: *** [install] Error 2 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 18:34:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 18:34:37 -0000 Subject: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version In-Reply-To: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> References: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> Message-ID: <063.a7a8b652222b0a3aa311b448d94f08d5@haskell.org> #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------+------------------------------------- Reporter: cetinsert | Owner: Fanael Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.6.1-rc1 (LLVM) | Keywords: llvm Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Fanael): * owner: => Fanael -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 18:58:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 18:58:04 -0000 Subject: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version In-Reply-To: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> References: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> Message-ID: <063.59ed16a0a44ef78aa69ec0680eba3cdc@haskell.org> #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------+------------------------------------- Reporter: cetinsert | Owner: Fanael Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.6.1-rc1 (LLVM) | Keywords: llvm Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D190 | -------------------------------------+------------------------------------- Changes (by Fanael): * differential: => Phab:D190 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 19:09:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 19:09:26 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.43605d0c1fc99552a63f8c7b662cfd6b@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Regarding the zlib problem (wrong hsc2hs options when comping zlib for 32bits on 64 bits), https://ghc.haskell.org/trac/ghc/ticket/3400#comment:16 (further changed in #7760) could not possibly help, because it only passes options to hsc2hs when compiling ghc https://github.com/ghc/hsc2hs/blob/4a0f67704d89712f8493a0c7eccffa9243d6ef09/ghc.mk#L30 and passes the options not from ghc but from CONF_* variables. I guess hsc2hs links to the correct version of libz after all, but the name it uses is a bit different, even though equivalent, to the name the internal checks in the haskell package zlib expect and so zlib panics. If that's the case I could file a bug report agains zlib. But if we go the route of automatically adding m32 to all invocations whenever we detect the 32bits on 64 bits scenario, fixes to zlib (nor to gtk) won't be needed and possibly some other problems, with yet different packages, will be avoided. For the record, the faulty call to hsc2hs looks rather reasonable, except for the mention of Dx86_64_BUILD_ARCH (are our i386 GHCs releases cross- compiled?), but even that should not cause any problems normally, I suppose. {{{ ("/home/mikolaj/local/bin/hsc2hs",["--cc=/usr/bin/gcc","-- ld=/usr/bin/gcc", "--cflag=-D__GLASGOW_HASKELL__=708","--cflag=-Dlinux_BUILD_OS=1", "--cflag=-Dx86_64_BUILD_ARCH=1","--cflag=-Dlinux_HOST_OS=1", "--cflag=-Di386_HOST_ARCH=1","--cflag=-Idist/build/autogen", "--cflag=-include","--cflag=dist/build/autogen/cabal_macros.h", "--lflag=-lz", [...], "-- lflag=-L/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/rts-1.0", "-- lflag=-Wl,-R,/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/rts-1.0"," --lflag=-lm", "--lflag=-lrt","-- lflag=-ldl","-o","dist/build/Codec/Compression/Zlib/Stream.hs", "Codec/Compression/Zlib/Stream.hsc"]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 19:51:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 19:51:55 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.15958682b3377f6a3261b0f653179fc4@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------- Reporter: jpet | Owner: Tarrasch Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 6.10.4 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Tarrasch): Just a quick update. Currently Peter's source notes patches are in review: https://phabricator.haskell.org/D169 Once those are merged, Peter can submit the DWARF emitting patches for review. Once also that is merged, I can submit my patches for stack traces on top of all that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 19:55:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 19:55:17 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.d1a47df40378d72c0537ed21c1f0a4bc@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nh2): Simon, I shall do that if you give me a suggestion where I shall put the note. Deterministic builds seem to depend on many things, so I'm unsure what the best location is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 19:56:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 19:56:26 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.c17cace44716ad4757d4b49e6cbd536f@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Thanks. I changed it to `foo = sum $ concat $ initsQ' $ [1..10000::Int]` (so that I don?t get any print-related stuff), and `-ddump-call-arity` gives me this code: {{{ #!hs [LclId, Arity=2, CallArity=2, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Arity=2, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 0] 150 0}] c = \ (x :: [Int]) (y [OS=OneShot] :: Int -> Int) -> letrec { go [Occ=LoopBreaker] :: [Int] -> Int -> Int [LclId, Arity=1, CallArity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Arity=1, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [30] 110 60}] go = \ (ds :: [Int]) -> case ds of _ [Occ=Dead] { [] -> y; : y ys -> let { ds1 [OS=OneShot] :: Int -> Int [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Arity=0, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] ds1 = go ys } in \ (ds2 :: Int) -> ds1 ($fNumInt_$c+ ds2 y) }; } in go x foo :: Int [LclIdX, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 634 0}] foo = c (++ ([]) (reverse1 ([]) ([]))) (letrec { go [Occ=LoopBreaker] :: Int# -> Queue Int -> Int -> Int [LclId, Arity=2, CallArity=2, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Arity=2, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [80 20] 464 0}] go = \ (x :: Int#) (eta :: Queue Int) -> let { b :: Int [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Arity=0, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] b = I# x } in case eta of _ [Occ=Dead] { Queue dt f r -> let { a :: Word# [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Arity=0, Value=False, ConLike=False, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 1 0}] a = plusWord# dt (__word 1) } in let { r :: [Int] [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Arity=0, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] r = : b r } in case word2Int# (popCnt# a) of _ [Occ=Dead] { __DEFAULT -> c (++ f (reverse1 r ([]))) (case x of wild { __DEFAULT -> go (+# wild 1) (Queue a f r); 10000 -> \ (eta :: Int) -> eta }); 1 -> let { ipv :: [Int] [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Arity=0, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 60 0}] ipv = ++ f (reverse1 r ([])) } in c (++ ipv (reverse1 ([]) ([]))) (case x of wild { __DEFAULT -> go (+# wild 1) (Queue a ipv ([])); 10000 -> \ (eta :: Int) -> eta }) } }; } in go 1 a) (I# 0) }}} The `go` inside `foo` is the interesting function. Its type has three arguments, but its outermost lambda only takes two. This is common when fusing a left-fold. Only that Call Arity is not sufficient to see that we?d want this to be expanded to thre arguments (`CallArity=3`). Would `CallArity=3` be correct? Yes, because the recursive calls to `go` call it with two arguments, pass that to `c`, which calls it at most once (so no sharing could be lost) with at least one argument. Unfortunately, that information is currently not available to the call arity analysis (?5.1.1 in the paper linked above). Call Arity is a forward analysis, so it is hard to see how it could make use of that. And even if it did, it would still have to pass a function (in that case a PAP) to `c`... :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 19:58:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 19:58:23 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.699bf0fd8881ca004bf455059588e363@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nh2): Another setback for this ticket is that parallel builds, e.g. `ghc -j4`, make builds non-deterministic. The generated closure names (`r4WO_closure...`, `r5BF_closure...`) vary with `-j` but don't without. Does anybody have an idea on how we could make sure that they are not "as shared", so that the names generated do not depend on the concurrency of the build? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 20:14:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 20:14:56 -0000 Subject: [GHC] #6016: On Windows, runhaskell hits an error on UTF-8 files with a BOM In-Reply-To: <045.febef025f59f8d7ebeb4dcc920991d5a@haskell.org> References: <045.febef025f59f8d7ebeb4dcc920991d5a@haskell.org> Message-ID: <060.12df8ad60810d4b0d3ce0aadc6587b40@haskell.org> #6016: On Windows, runhaskell hits an error on UTF-8 files with a BOM -------------------------------------+------------------------------------- Reporter: vsajip | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.0.4 (Parser) | Keywords: BOM Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: #1744 rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D176 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"9e939403241b758a685834c9ff62edcd3172a2cf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9e939403241b758a685834c9ff62edcd3172a2cf" StringBuffer should not contain initial byte-order mark (BOM) Summary: Just skipping over a BOM, but leaving it in the Stringbuffer, is not sufficient. The Lexer calls prevChar when a regular expression starts with '^' (which is a shorthand for '\n^'). It would never match on the first line, since instead of '\n', prevChar would still return '\xfeff'. Test Plan: validate Reviewers: austin, ezyang Reviewed By: austin, ezyang Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D176 GHC Trac Issues: #6016 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 20:14:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 20:14:57 -0000 Subject: [GHC] #8886: sync-all: END actions result in confusing error message In-Reply-To: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> References: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> Message-ID: <056.28b3ad5672d50f026f46fbfd381f946d@haskell.org> #8886: sync-all: END actions result in confusing error message -------------------------------------+------------------------------------- Reporter: fw | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Trac & Git | Version: Resolution: fixed | Keywords: sync-all Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"0f31c2e5c1cf240a78221bb09578f6eb7084ada5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0f31c2e5c1cf240a78221bb09578f6eb7084ada5" Cleanup and better documentation of sync-all script Summary: Rumor has it that sync-all is slowly on the way out. Now that all subrepositories have been turned into git submodules, sync-all might not be needed anymore. Nevertheless, here are some changes I had made while trying to understand why it existed in the first place: * update comments + help text * rename some variables for maintainability * s/branch_name/remote_name/ origin is the name of a remote, not a branch * s/repo_base/remote_root/ the word *remote* is key here * s/defaultrepo/default_root/ this was a darcsism, and it doesn't refer to a repository but to the root directory of all repositories * small tweaks * .git can be a file nowadays * don't skip END actions on exceptions #8886 reverts d523f9b3d4ce3463e8816cad2139ea397e00f8d1 Test Plan: Why revert d523f9b3d4ce3463e8816cad2139ea397e00f8d1? I put an old haddock repository from http://darcs.haskell.org/haddock2.git back in my tree. Now, when running `sync-all get`, the following happens: 1. I get a cryptic error saying: fatal: reference is not a tree: 5412c262f403e52be45d607b34eb3a5806ea2a76 Unable to checkout '5412c262f403e52be45d607b34eb3a5806ea2a76' in submodule path 'utils/haddock' git failed: 256 at ./sync-all line 112. 2. sync-all checks if maybe an old haddock repository is present 3. I get a clear warning saying: ============================ ATTENTION! You have an old haddock repository in your GHC tree! Please remove it (e.g. "rm -r utils/haddock"), and then run "./sync-all get" to get the new repository. ============================ Without commit d523f9b3d4ce3463e8816cad2139ea397e00f8d1 reverted, steps 2 and 3 were skipped. The problem that commit tried to solve, is now solved with 7012ed8515100b4947383e93b82dbff7a0aa835c. Reviewers: nomeata, austin, hvr Reviewed By: austin, hvr Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D178 GHC Trac Issues: #8886, #9212 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 20:14:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 20:14:56 -0000 Subject: [GHC] #9212: Cleanup of sync-all In-Reply-To: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> References: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> Message-ID: <060.3a28af206492548079653275c3748b49@haskell.org> #9212: Cleanup of sync-all -------------------------------------+------------------------------------ Reporter: thomie | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"0f31c2e5c1cf240a78221bb09578f6eb7084ada5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0f31c2e5c1cf240a78221bb09578f6eb7084ada5" Cleanup and better documentation of sync-all script Summary: Rumor has it that sync-all is slowly on the way out. Now that all subrepositories have been turned into git submodules, sync-all might not be needed anymore. Nevertheless, here are some changes I had made while trying to understand why it existed in the first place: * update comments + help text * rename some variables for maintainability * s/branch_name/remote_name/ origin is the name of a remote, not a branch * s/repo_base/remote_root/ the word *remote* is key here * s/defaultrepo/default_root/ this was a darcsism, and it doesn't refer to a repository but to the root directory of all repositories * small tweaks * .git can be a file nowadays * don't skip END actions on exceptions #8886 reverts d523f9b3d4ce3463e8816cad2139ea397e00f8d1 Test Plan: Why revert d523f9b3d4ce3463e8816cad2139ea397e00f8d1? I put an old haddock repository from http://darcs.haskell.org/haddock2.git back in my tree. Now, when running `sync-all get`, the following happens: 1. I get a cryptic error saying: fatal: reference is not a tree: 5412c262f403e52be45d607b34eb3a5806ea2a76 Unable to checkout '5412c262f403e52be45d607b34eb3a5806ea2a76' in submodule path 'utils/haddock' git failed: 256 at ./sync-all line 112. 2. sync-all checks if maybe an old haddock repository is present 3. I get a clear warning saying: ============================ ATTENTION! You have an old haddock repository in your GHC tree! Please remove it (e.g. "rm -r utils/haddock"), and then run "./sync-all get" to get the new repository. ============================ Without commit d523f9b3d4ce3463e8816cad2139ea397e00f8d1 reverted, steps 2 and 3 were skipped. The problem that commit tried to solve, is now solved with 7012ed8515100b4947383e93b82dbff7a0aa835c. Reviewers: nomeata, austin, hvr Reviewed By: austin, hvr Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D178 GHC Trac Issues: #8886, #9212 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 20:14:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 20:14:57 -0000 Subject: [GHC] #9449: GHC.Prim documentation says "Safe Inferred" In-Reply-To: <047.6ad8c2a212ab3e49ebf79357b664b6f9@haskell.org> References: <047.6ad8c2a212ab3e49ebf79357b664b6f9@haskell.org> Message-ID: <062.2981a71b06e432a957e6fdb16f69675d@haskell.org> #9449: GHC.Prim documentation says "Safe Inferred" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: | Version: 7.8.2 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D182 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"3be704ab373ecd84d97b832c0d4f59dd7cb9e0ea/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3be704ab373ecd84d97b832c0d4f59dd7cb9e0ea" genprimopcode: GHC.Prim is Unsafe (#9449) Summary: Make sure the documentation for `GHC.Prim` adequately reflects the fact it is unsafe. Also clean up some 80-column violations. Signed-off-by: Austin Seipp Test Plan: Build documentation, check `GHC.Prim`. It's properly marked as `Unsafe`. Reviewers: hvr, goldfire, ezyang Reviewed By: ezyang Subscribers: nomeata, simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D182 GHC Trac Issues: #9449 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 20:14:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 20:14:58 -0000 Subject: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version In-Reply-To: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> References: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> Message-ID: <063.fa658242304ce1374bce4f5b06c7b220@haskell.org> #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------+------------------------------------- Reporter: cetinsert | Owner: Fanael Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.6.1-rc1 (LLVM) | Keywords: llvm Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D190 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"918719b936b878ab660f20ceef8afc9e3a898c5a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="918719b936b878ab660f20ceef8afc9e3a898c5a" Set llc and opt commands on all platforms Summary: LLVM llc and opt commands should be set on all platforms, including Windows. If they're not, GHC tries to execute an unnamed executable, resulting in error messages such as: Error (figuring out LLVM version): : runInteractiveProcess: invalid argument (Invalid argument) : Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM This regression was introduced in e6bfc596. Test Plan: Build GHC and test if --info shows sensible values of "LLVM llc command" and "LLVM opt command" Reviewers: austin, #ghc Reviewed By: austin, #ghc Subscribers: austin Projects: #ghc Differential Revision: https://phabricator.haskell.org/D190 GHC Trac Issues: #7143 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 20:22:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 20:22:15 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.75c95049d27a4998c57c7a851b9acbea@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Just to keep us on the same page, I rewrote `scanl'` like this so it can be written back to a simple form. {{{#!hs {-# NOINLINE [1] scanl' #-} scanl' :: (b -> a -> b) -> b -> [a] -> [b] scanl' f q ls = q `seq` q : (case ls of [] -> [] x:xs -> scanl' f (f q x) xs) {-# RULES "scanl'" [~1] forall f a bs . scanl' f a bs = build (\c n -> a `c` foldr (scanlFB' f c) (flipSeqScanl' n) bs a) "scanl'List" [1] forall f a bs . foldr (scanlFB' f (:)) (flipSeqScanl' []) bs a = tailScanl' f a bs #-} {-# INLINE [0] scanlFB' #-} scanlFB' f c = \b g x -> let b' = f x b in b' `seq` b' `c` g b' {-# INLINE [0] flipSeqScanl' #-} flipSeqScanl' = flip seq {-# NOINLINE [1] tailScanl' #-} tailScanl' f a bs = a `seq` foldr (scanlFB' f (:)) (flip seq []) bs a }}} This doesn't seem to affect the problem, however. I am curious if there is a way to manually force whatever's getting the wrong arity to get the right one. Bertram pointed out that fusing `inits` on the right with an expensive producer is ''really'' bad, and I realized that fusing it on the right with something that leads to lots of reboxing is also really bad. So for now, probably the best thing is just to NOINLINE inits altogether. Unrelatedly: I was successful in my quest to write rules to make `concat` and `inits` fuse into something that's actually good (in case anyone actually uses such a thing). Interestingly the arity/strictness analysis only works on it if it's inlined (maybe you can figure out a fix for that?): {{{#!hs -- We don't particularly like the idea of inlining this function, since it's -- a bit large, but it appears to be necessary to get the analyses to work -- right and avoid eating all available memory. Making this INLINE [0] to -- be able to rewrite it to a simpler form unfortunately seems to make it miss some -- analysis that speeds it up by a relatively small but still significant amount. -- There may be some way around this problem, but I haven't found it yet. {-# INLINE concatInitsFB #-} concatInitsFB xs cons nil = let go _ _ [] = nil go n k (y:ys) | n == k = go (n+1) 0 xs | otherwise = y `cons` go n (k+1) ys in go (1::Int) 0 xs {-# RULES -- We might catch concat before it's rewritten. "concatInits1" forall xs . concat (inits xs) = build (concatInitsFB xs) -- If not, we might be able to recognize its rewritten form. "concatInits2" forall c n xs . foldr (\x y -> foldr c y x) n (inits xs) = concatInitsFB xs c n #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 20:29:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 20:29:08 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.f15117fe004fb0ed62d05b1043d2479e@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > This doesn't seem to affect the problem, however. Yes, I don?t think the problem in this particular case lies with init per se. I think it?s more like concat, but only when part of the recursion (the `c` above) is not inlined. That might also be what you observe. > I am curious if there is a way to manually force whatever's getting the wrong arity to get the right one Not with list fusion as we have it right now, I think. It should work with https://github.com/takano-akio/ww-fusion (which I should follow up on again). I don?t think a rule for `concat (inits)` is worth it, but it may help us understand the problem better. I wonder if maybe the rule for `concat` can be rewritten so that the resulting recursion is nicer, but I don?t see it right now (but I?m too jetlagged to think anyways). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 20:29:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 20:29:29 -0000 Subject: [GHC] #6016: On Windows, runhaskell hits an error on UTF-8 files with a BOM In-Reply-To: <045.febef025f59f8d7ebeb4dcc920991d5a@haskell.org> References: <045.febef025f59f8d7ebeb4dcc920991d5a@haskell.org> Message-ID: <060.0436e13268073810fd578f856e5b3c97@haskell.org> #6016: On Windows, runhaskell hits an error on UTF-8 files with a BOM -------------------------------------+------------------------------------- Reporter: vsajip | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.0.4 (Parser) | Keywords: BOM Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: #1744 rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D176 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 20:58:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 20:58:49 -0000 Subject: [GHC] #1744: treat byte order mark as zero-width whitespace In-Reply-To: <044.80a63f9733be4ce7239a3d4908550ac5@haskell.org> References: <044.80a63f9733be4ce7239a3d4908550ac5@haskell.org> Message-ID: <059.c54041c51a644b9d5708854199463e4a@haskell.org> #1744: treat byte order mark as zero-width whitespace -------------------------------------+------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.8 (Parser) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 6016 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => None/Unknown * related: => 6016 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 21:00:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 21:00:13 -0000 Subject: [GHC] #1744: treat byte order mark as zero-width whitespace In-Reply-To: <044.80a63f9733be4ce7239a3d4908550ac5@haskell.org> References: <044.80a63f9733be4ce7239a3d4908550ac5@haskell.org> Message-ID: <059.e858c7611094b0200e468d62ac7f6471@haskell.org> #1744: treat byte order mark as zero-width whitespace -------------------------------------+------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.8 (Parser) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: #6016 rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => GHC rejects valid program * related: 6016 => #6016 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 21:12:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 21:12:37 -0000 Subject: [GHC] #8825: ghc can't determine gcc version on ru_RU locale In-Reply-To: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> References: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> Message-ID: <060.fb4e48c3811b606889534f0865d8e75b@haskell.org> #8825: ghc can't determine gcc version on ru_RU locale -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D185 | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"4d4d07704ee78221607a18b8118294b0aea1bac4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4d4d07704ee78221607a18b8118294b0aea1bac4" systools: fix gcc version detecton on non-english locale Summary: ghc runs 'gcc -v' to check if we run under vanilla gcc or disaguised clang by checking for string "gcc version " But this check does not always work as gcc has that string localized via gettext mechanism: (some gcc's locale strings) be.po-msgstr "?????? gcc %s\n" da.po-msgstr "GCC version %s\n" de.po-msgstr "gcc-Version %s %s\n" el.po-msgstr "?????? gcc %s\n" ... To ping gcc to English locale we now override environment variable with 'LANGUAGE=en' value. Fixes Issue #8825 Signed-off-by: Sergei Trofimovich Test Plan: validate Reviewers: austin Reviewed By: austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D185 GHC Trac Issues: #8825 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 21:43:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 21:43:22 -0000 Subject: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version In-Reply-To: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> References: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> Message-ID: <063.ceadde0550e5d6b34fe06c7d1010ee48@haskell.org> #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------+------------------------------------- Reporter: cetinsert | Owner: Fanael Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.6.1-rc1 (LLVM) | Keywords: llvm Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D190 | -------------------------------------+------------------------------------- Changes (by Fanael): * status: new => merge Comment: Should be fixed in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 21:43:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 21:43:33 -0000 Subject: [GHC] #8825: ghc can't determine gcc version on ru_RU locale In-Reply-To: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> References: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> Message-ID: <060.4330c1897e8311826316bd041d489cb4@haskell.org> #8825: ghc can't determine gcc version on ru_RU locale -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D185 | -------------------------------------+------------------------------------- Changes (by slyfox): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 22:02:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 22:02:20 -0000 Subject: [GHC] #9536: Implement foldr/cons/build Message-ID: <045.6ebfec57f4d10be70298126e95b3e1e6@haskell.org> #9536: Implement foldr/cons/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.9 Keywords: fusion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There seem to be various issues with general `fold/cons` and even `cons/build` rules, but it seems pretty clear to me that the simple `fold/cons/build` rule is a good idea. It doesn't do much for nofib allocation, but it seems to improve some other analyses and speed several benchmarks up, including speeding up some things that other fusion changes slowed down. I say "seems to" because I never trust my timings much at all. {{{#!hs {-# RULES "foldr/cons/build" forall c n x (g::forall b. (a->b->b) -> b -> b) . foldr c n (x:build g) = c x (g c n) #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 22:05:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 22:05:41 -0000 Subject: [GHC] #9536: Implement foldr/cons/build In-Reply-To: <045.6ebfec57f4d10be70298126e95b3e1e6@haskell.org> References: <045.6ebfec57f4d10be70298126e95b3e1e6@haskell.org> Message-ID: <060.d3ac8e43563b6c9cb857521284d8f6fb@haskell.org> #9536: Implement foldr/cons/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.4 Component: | Version: 7.9 libraries/base | Keywords: fusion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 22:14:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 22:14:42 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.929db6417fb83604280a3eb8f46c9673@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.9 (LLVM) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Fanael): Replying to [comment:12 awson]: > For example, if > {{{ > @T8947_t1_info_itable = constant %T8947_t1_entry_struct<{i64 add (i64 sub (i64 ptrtoint (i8* @S1fL_srt$alias to i64),i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @T8947_t1_info to i64)),i64 0), i64 4294967299, i64 0, i64 64424509455}>, section "X98A__STRIP,__me3", align 8 > }}} > gets rewritten to > {{{ > @T8947_t1_info_itable = constant %T8947_t1_entry_struct<{i32 add (i32 sub (i32 ptrtoint (i8* @S1i6_srt$alias to i32),i32 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @T8947_t1_info to i32)),i32 0), i32 0, i64 4294967299, i64 0, i64 64424509455}>, section "X98A__STRIP,__me3", align 8 > }}} > > LLVM instead of > {{{ > T8947_t1_info_itable: > .quad S1i6_srt-T8947_t1_info > }}} > generates (assembler spits {{{Error: invalid operands (.rdata and *ABS* sections) for `&'}}}) > {{{ > T8947_t1_info_itable: > .long (S1i6_srt&-1)-(T8947_t1_info&-1) > .long 0 # 0x0 > }}} > while we want it to be > {{{ > T8947_t1_info_itable: > .long S1i6_srt-T8947_t1_info > .long 0 # 0x0 > }}} > > I'm in no way an LLVM expert and know very little about it. Is there a way to make LLVM generate the code we want or are we use the mangler here? Any thoughts? Yes, there is. Use `trunc`, for example: {{{ %foo = type <{i32, i32}> @aaa = global i32 5 @bbb = global i32 5 @foo = constant %foo<{i32 trunc(i64 sub(i64 ptrtoint (i32* @aaa to i64), i64 ptrtoint (i32* @bbb to i64)) to i32), i32 0}> }}} LLVM will generate {{{ foo: .long aaa-bbb .long 0 # 0x0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 22:19:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 22:19:04 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.cf24665ca2696829f258b82f71347bc7@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:26 nomeata]: > > This doesn't seem to affect the problem, however. > > Yes, I don?t think the problem in this particular case lies with `init` per se. I think it?s more like `concat`, but only when part of the recursion (the `c` above) is not inlined. That might also be what you observe. I hope you'll be able to tease this apart; `inits` isn't very important in the grand scheme of things, but `concat` is. > > I am curious if there is a way to manually force whatever's getting the wrong arity to get the right one > > Not with list fusion as we have it right now, I think. It should work with https://github.com/takano-akio/ww-fusion (which I should follow up on again). That looks very interesting, by which I mean I couldn't understand it at all the first time around. I'll have to try again. If it can really solve this class of problem in a fairly thorough fashion, it will certainly be worth the added complexity. > I wonder if maybe the rule for `concat` can be rewritten so that the resulting recursion is nicer, but I don?t see it right now (but I?m too jetlagged to think anyways). Rest well! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 22:50:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 22:50:18 -0000 Subject: [GHC] #9537: concatMap does not participate in list fusion Message-ID: <045.e14a158c8be66f6d40a93a99a32fda56@haskell.org> #9537: concatMap does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.9 Keywords: fusion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Joachim Breitner raised this issue in an [http://www.haskell.org/pipermail /haskell-cafe/2011-December/097228.html email to haskell-cafe] in 2011, but he never got a response. For some reason, list comprehensions desugar to `concatMap` forms written to fuse, but the actual `concatMap` function is not written so. Unless there is a good reason for this, we should make it fuse. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 23:10:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 23:10:01 -0000 Subject: [GHC] #9538: unwords does not participate in list fusion Message-ID: <045.87132da34ffe57a83ce94c966b9cc098@haskell.org> #9538: unwords does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm not quite sure how far this can go, but `unwords` should almost certainly be a good consumer or a good consumer. Currently it is neither. Making it a good consumer is trivial, given `concatMap` that fuses: {{{#!hs unwords = tail . concatMap (' ':) }}} Alternatively, we should be able to make it a good producer without too much trouble, I think. I have my doubts about making it both. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 23:17:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 23:17:51 -0000 Subject: [GHC] #9538: unwords does not participate in list fusion In-Reply-To: <045.87132da34ffe57a83ce94c966b9cc098@haskell.org> References: <045.87132da34ffe57a83ce94c966b9cc098@haskell.org> Message-ID: <060.642eb449495e0d7a2ea427400a236b90@haskell.org> #9538: unwords does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => invalid Comment: Needs more thinking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 1 23:52:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Sep 2014 23:52:14 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation Message-ID: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.2 Keywords: stm | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For background, please see [http://stackoverflow.com/questions/25536604 /huge-memory-consumption-for-simple-multithreaded- haskell/25560047#25560047 this SO question] When using TQueue, a sufficiently fast/persistent writer can result in the reader never getting scheduled, causing the queue to continually grow and lost concurrency. I believe the issue is caused by the definition of readTQueue: {{{ readTQueue :: TQueue a -> STM a readTQueue (TQueue read write) = do xs <- readTVar read case xs of (x:xs') -> do writeTVar read xs' return x [] -> do ys <- readTVar write case ys of [] -> retry _ -> case reverse ys of [] -> error "readTQueue" (z:zs) -> do writeTVar write [] writeTVar read zs return z }}} Note that the last `case` needs to traverse the write-end of the queue within the STM transaction. If the list is sufficiently large, a writer can commit a new transaction much more quickly, invalidating the read transaction. If threads continue to write to the queue, the reader will never get an opportunity to commit (and the list will grow, exacerbating the problem). This alternative definition seems to fix the problem, but I don't know if there are other drawbacks to using it. {{{ readTQueue' :: TQueue a -> STM a readTQueue' (TQueue read write) = do xs <- readTVar read case xs of (x:xs') -> do writeTVar read xs' return x [] -> do ys <- readTVar write case ys of [] -> retry _ -> do writeTVar write [] let (z:zs) = reverse ys writeTVar read zs return z }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 03:01:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 03:01:31 -0000 Subject: [GHC] #367: Infinite loops can hang Concurrent Haskell In-Reply-To: <046.5a2b87104f229d7899f0f85ea5bfdf9e@haskell.org> References: <046.5a2b87104f229d7899f0f85ea5bfdf9e@haskell.org> Message-ID: <061.b033548c1a74a22ca155884105397d2d@haskell.org> #367: Infinite loops can hang Concurrent Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: scheduler Operating System: | allocation Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: concurrent/should_run/T367, | concurrent/should_run/T367_letnoescape| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jberryman): As a user I'm having trouble understanding if the bug being discussed is the one reported. To be clear, is the following (very similar to #8521) an instance of this bug? Compiled with ghc 7.8.3 with `-O2 -threaded`, run with `+RTS -N` on a machine with two real cores. {{{ module Main where import Data.IORef import Control.Concurrent main = do r <- newIORef False putStrLn "About to fork" forkIO $ f r threadDelay 1000000 -- 1 second putStrLn "Why is this never printed?!" writeIORef r True -- and why do we never exit? f :: IORef Bool -> IO () f r = readIORef r >>= \b-> if b then print "Done" else f r }}} This wouldn't seem to have anything to do with whether `f`'s thread can be pre-empted or not, which is why I'm unsure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 03:13:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 03:13:17 -0000 Subject: [GHC] #9540: unwords is not a good producer Message-ID: <045.cf07c524c3885055d6c8e1249648041f@haskell.org> #9540: unwords is not a good producer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: fusion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I think we can do something like this, once we've fixed `unfoldr`: {{{#!hs unwords = unfoldr go where go [] = Nothing go ("":ws) = Just (' ', ws) go ((l:ls):ws) = Just (l, ls:ws) }}} With my draft `unfoldr`, GHC turns this into {{{#!hs lvl_r1EN lvl_r1EN = C# ' ' Rec { unwords_$sgo unwords_$sgo = \ sc_s1Gx sc1_s1Gy -> case sc_s1Gx of _ { [] -> : lvl_r1EN (unwords_go sc1_s1Gy); : l_a1Ew ls_a1Ex -> : l_a1Ew (unwords_$sgo ls_a1Ex sc1_s1Gy) } unwords_go unwords_go = \ b1_a1Fb -> case b1_a1Fb of _ { [] -> []; : ds_d1F5 ws_a1Ev -> case ds_d1F5 of _ { [] -> : lvl_r1EN (unwords_go ws_a1Ev); : l_a1Ew ls_a1Ex -> : l_a1Ew (unwords_$sgo ls_a1Ex ws_a1Ev) } } end Rec } unwords unwords = \ b'_a1F9 -> unwords_go b'_a1F9 }}} To my untrained eye, that looks pretty reasonable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 06:04:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 06:04:19 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.b585d26c9cfa0f8b7cdadbacb8fd463c@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.9 (LLVM) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by awson): Replying to [comment:21 Fanael]: > Yes, there is. Use `trunc`, for example: > > {{{ > %foo = type <{i32, i32}> > @aaa = global i32 5 > @bbb = global i32 5 > @foo = constant %foo<{i32 trunc(i64 sub(i64 ptrtoint (i32* @aaa to i64), i64 ptrtoint (i32* @bbb to i64)) to i32), i32 0}> > > }}} > > LLVM will generate > {{{ > foo: > .long aaa-bbb > .long 0 # 0x0 > }}} AFAIR, the `trunc` alone is '''not''' sufficient. What you propose in fact is to '''declare''' a pair of 32-bit int variables instead of one 64-bit pointer global variable, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 07:05:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 07:05:12 -0000 Subject: [GHC] #367: Infinite loops can hang Concurrent Haskell In-Reply-To: <046.5a2b87104f229d7899f0f85ea5bfdf9e@haskell.org> References: <046.5a2b87104f229d7899f0f85ea5bfdf9e@haskell.org> Message-ID: <061.f97155916b56264c89ea1bb7bb86c41d@haskell.org> #367: Infinite loops can hang Concurrent Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: scheduler Operating System: | allocation Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: concurrent/should_run/T367, | concurrent/should_run/T367_letnoescape| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Yes, this is an instance of the bug. Does it work with `-fno-omit- yields`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 07:50:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 07:50:22 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.1650ce9f0a07d1f16172de4cd8086e74@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): We can separate this problem into two: 1. non-determinism in the ABI, which leads to different ABI hashes being generated, and different package identities in the package database. This annoys OS packagers, who like to be able to generate deterministic package names. 2. non-determinism in the generated object file. (who cares about this and why?) (1) is a prerequisite for (2), and (2) is more difficult. The ticket description contains a list of issues that need to be fixed for (1). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 07:56:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 07:56:55 -0000 Subject: [GHC] #8052: make ghci look for the files made by -dynamic-too In-Reply-To: <046.ee22f2889d89ec48dc121179c565ce39@haskell.org> References: <046.ee22f2889d89ec48dc121179c565ce39@haskell.org> Message-ID: <061.f3cf23b996eff13cb8d670efe3904920@haskell.org> #8052: make ghci look for the files made by -dynamic-too -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.7 Component: GHCi | Keywords: Resolution: duplicate | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: hvr (added) * status: new => closed * resolution: => duplicate Comment: Closing as duplicate of #8726 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 08:57:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 08:57:57 -0000 Subject: [GHC] #9512: T9329 fails test on unregisterised i386, amd64 (was: T9329 fails test on unregisterised i386) In-Reply-To: <045.e8f5ea5daa466f61185e5401527f83c6@haskell.org> References: <045.e8f5ea5daa466f61185e5401527f83c6@haskell.org> Message-ID: <060.8a9b4688fdd4cc6f573fe6dfa3e07e2c@haskell.org> #9512: T9329 fails test on unregisterised i386, amd64 -------------------------------------------+--------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: T9329 | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 09:01:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 09:01:06 -0000 Subject: [GHC] #9519: Add a way to mask thread preemption via fired timer for a computation In-Reply-To: <047.26171a8aa89618b26a4ae216870ee32e@haskell.org> References: <047.26171a8aa89618b26a4ae216870ee32e@haskell.org> Message-ID: <062.7a943cf9b587ec76ebe393052fbde7da@haskell.org> #9519: Add a way to mask thread preemption via fired timer for a computation -------------------------------------+------------------------------------- Reporter: abbradar | Owner: simonmar Type: feature | Status: infoneeded request | Milestone: Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => infoneeded Comment: I doubt that this would be easily implementable, the RTS assumes that worker threads are interchangeable and I think it would be difficult (and error-prone) to change that assumption. The right way to deal with thread-local state is to use a bound thread (`forkOS`). Is that a problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 09:04:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 09:04:34 -0000 Subject: [GHC] #9538: unwords does not participate in list fusion In-Reply-To: <045.87132da34ffe57a83ce94c966b9cc098@haskell.org> References: <045.87132da34ffe57a83ce94c966b9cc098@haskell.org> Message-ID: <060.db1a37e79e13607a10b310739da61991@haskell.org> #9538: unwords does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by slyfox: Old description: > I'm not quite sure how far this can go, but `unwords` should almost > certainly be a good consumer or a good consumer. Currently it is neither. > Making it a good consumer is trivial, given `concatMap` that fuses: > > {{{#!hs > unwords = tail . concatMap (' ':) > }}} > > Alternatively, we should be able to make it a good producer without too > much trouble, I think. I have my doubts about making it both. New description: I'm not quite sure how far this can go, but `unwords` should almost certainly be a good consumer or a good producer. Currently it is neither. Making it a good consumer is trivial, given `concatMap` that fuses: {{{#!hs unwords = tail . concatMap (' ':) }}} Alternatively, we should be able to make it a good producer without too much trouble, I think. I have my doubts about making it both. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 09:12:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 09:12:10 -0000 Subject: [GHC] #9519: Add a way to mask thread preemption via fired timer for a computation In-Reply-To: <047.26171a8aa89618b26a4ae216870ee32e@haskell.org> References: <047.26171a8aa89618b26a4ae216870ee32e@haskell.org> Message-ID: <062.9169d734aea0ffdece72fef962ccdbd1@haskell.org> #9519: Add a way to mask thread preemption via fired timer for a computation -------------------------------------+------------------------------------- Reporter: abbradar | Owner: simonmar Type: feature | Status: infoneeded request | Milestone: Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by abbradar): Well, not really -- it was just an idea that, if could be implemented more or less easily, could allow using lightweight threads instead. Thanks for the clarification! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 09:16:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 09:16:39 -0000 Subject: [GHC] #8052: make ghci look for the files made by -dynamic-too In-Reply-To: <046.ee22f2889d89ec48dc121179c565ce39@haskell.org> References: <046.ee22f2889d89ec48dc121179c565ce39@haskell.org> Message-ID: <061.b308ac7c96a845ccfe9e2e1117bc88a9@haskell.org> #8052: make ghci look for the files made by -dynamic-too -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.7 Component: GHCi | Keywords: Resolution: duplicate | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): I guess it was #8736 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 09:26:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 09:26:45 -0000 Subject: [GHC] #9513: Building GHC on Windows In-Reply-To: <048.511f109539d5b05fe095941eac814f1c@haskell.org> References: <048.511f109539d5b05fe095941eac814f1c@haskell.org> Message-ID: <063.b2aef452703eb4094aa739718038b4f8@haskell.org> #9513: Building GHC on Windows ----------------------------------------------+--------------------------- Reporter: srutownik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by srutownik): * architecture: x86_64 (amd64) => x86 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 09:29:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 09:29:24 -0000 Subject: [GHC] #9513: Building GHC on Windows In-Reply-To: <048.511f109539d5b05fe095941eac814f1c@haskell.org> References: <048.511f109539d5b05fe095941eac814f1c@haskell.org> Message-ID: <063.5b1dea014835141fb0c66a1ce6aac202@haskell.org> #9513: Building GHC on Windows ----------------------------------------------+--------------------------- Reporter: srutownik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by srutownik): I have finally succeeded -- it was necessary to use MSYS2 as building environment. I have posted further details in the mail http://www.haskell.org/pipermail/ghc-devs/2014-September/006217.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 09:49:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 09:49:50 -0000 Subject: [GHC] #9535: Remove max_bytes_used from haddock tests In-Reply-To: <046.b450aff06541c96c843901eaaf37ab41@haskell.org> References: <046.b450aff06541c96c843901eaaf37ab41@haskell.org> Message-ID: <061.43d051e571f49a9977eca6fe321f9123@haskell.org> #9535: Remove max_bytes_used from haddock tests -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"8c427ebe9c34b9bcecd41fb0584d24989c00ffe6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8c427ebe9c34b9bcecd41fb0584d24989c00ffe6" Remove max_bytes_used test from haddock test cases Summary: as these are not very reliable, and the advice to make them reliable is hard to apply to them. (This is just my practicing phab...) Test Plan: validate Reviewers: austin Reviewed By: austin Subscribers: carter, ezyang, simonmar Differential Revision: https://phabricator.haskell.org/D188 GHC Trac Issues: #9535 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 12:01:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 12:01:19 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.77e34f91f40fdc3e8a5e34b3b8e2d731@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nh2): @simonmar: Then I shall leave this ticket to issues concerning (1), and create a separate one for byte-identical compilation. Why would you want byte-identical compilation (or, how Debian calls it, "reproducible builds")? There are a few reasons (3 is the key point for me right now): 1. Distributions want it (see https://wiki.debian.org/ReproducibleBuilds#Why_do_we_want_reproducible_builds.3F) 2. It allows users of open source projects (e.g. Tor, TrueCrypt had famous efforts in this direction) to verify that the binary they downloaded really is built from the unmodified source 3. It gives recompilation avoidance in build systems outside of GHC. If the binary you just produced is byte-identical to what was already there, you can stop (e.g. don't need to run tests in CI etc.). And finally, a more-belief-than-evidence-supported point: 5. It will improve binary distributions of cabal packages and similar things. For example, I would like to build a Haskell equivalent to `ccache`, and having byte-identical output for the same input would make that much easier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 13:28:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 13:28:36 -0000 Subject: [GHC] #367: Infinite loops can hang Concurrent Haskell In-Reply-To: <046.5a2b87104f229d7899f0f85ea5bfdf9e@haskell.org> References: <046.5a2b87104f229d7899f0f85ea5bfdf9e@haskell.org> Message-ID: <061.8f3b6f48d7da86754812130665ac6bfa@haskell.org> #367: Infinite loops can hang Concurrent Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: scheduler Operating System: | allocation Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: concurrent/should_run/T367, | concurrent/should_run/T367_letnoescape| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jberryman): Replying to [comment:40 simonmar]: > Yes, this is an instance of the bug. Does it work with `-fno-omit- yields`? Okay, thank you. Yes `-fno-omit-yields` works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 13:56:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 13:56:09 -0000 Subject: [GHC] #9541: ghc: panic, "RegAlloc.Liveness.computeLivenss; SCCs aren't in reverse dependent order" In-Reply-To: <046.68efa89057831cb9c8ddc6a98623ef69@haskell.org> References: <046.68efa89057831cb9c8ddc6a98623ef69@haskell.org> Message-ID: <061.52f38e7d52f62854ccb23f9087c36326@haskell.org> #9541: ghc: panic, "RegAlloc.Liveness.computeLivenss; SCCs aren't in reverse dependent order" -------------------------------------+------------------------------------- Reporter: aleator | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): Chances it was fixed by #9303 (will be in ghc-7.8.4) Could you check if ghc-HEAD still has this bug, or maybe attach source sample here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 13:57:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 13:57:17 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.fb49540322178cacafa65c801567f298@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.9 (LLVM) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Fanael): Replying to [comment:22 awson]: > AFAIR, the `trunc` alone is '''not''' sufficient. What you propose in fact is to '''declare''' a pair of 32-bit int variables instead of one 64-bit pointer global variable, right? As shown in the example, yes. The ideal solution would be to convert that truncated value back to `i64`, but even though the LLVM docs say that `sext` and `zext` are valid constant expressions, they don't work and yield an "Unsupported expression in static initializer" error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 14:47:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 14:47:53 -0000 Subject: [GHC] #9542: GHC-IO-Handle-Text.hputStr' and writeBlocks look like they need refactoring Message-ID: <045.245970e68839d437b57a6968a4cc5957@haskell.org> #9542: GHC-IO-Handle-Text.hputStr' and writeBlocks look like they need refactoring -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The boundary between `writeBlocks` and `hPutStr'` looks badly drawn, with pieces of buffering type on either side. I would also speculate that one or more CRLF-related helper functions may be in order. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 14:53:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 14:53:18 -0000 Subject: [GHC] #9542: GHC-IO-Handle-Text.hPutStr' and writeBlocks look like they need refactoring (was: GHC-IO-Handle-Text.hputStr' and writeBlocks look like they need refactoring) In-Reply-To: <045.245970e68839d437b57a6968a4cc5957@haskell.org> References: <045.245970e68839d437b57a6968a4cc5957@haskell.org> Message-ID: <060.4e42dfa7d99b0ccd98333fe741de2422@haskell.org> #9542: GHC-IO-Handle-Text.hPutStr' and writeBlocks look like they need refactoring -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): We probably also want to make sure that `hPutStr'`, `writeBlocks`, and/or whatever other pieces are inlined into `hPutStr` and `hPutStrLn` to avoid unnecessary tests for `add_nl`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 15:11:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 15:11:40 -0000 Subject: [GHC] #6077: Respect XDG_CONFIG_HOME In-Reply-To: <045.4be78870b39bed231ff23249aec382c8@haskell.org> References: <045.4be78870b39bed231ff23249aec382c8@haskell.org> Message-ID: <060.08fe15794734280511495209086e8251@haskell.org> #6077: Respect XDG_CONFIG_HOME -------------------------------------+------------------------------------- Reporter: So8res | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.4.1 Component: None | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Other | Blocked By: 5966 Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by god): * status: closed => new * resolution: duplicate => * blockedby: => 5966 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 15:12:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 15:12:51 -0000 Subject: [GHC] #6077: Respect XDG_CONFIG_HOME In-Reply-To: <045.4be78870b39bed231ff23249aec382c8@haskell.org> References: <045.4be78870b39bed231ff23249aec382c8@haskell.org> Message-ID: <060.e28549f9a3645fdd971c59506e794f52@haskell.org> #6077: Respect XDG_CONFIG_HOME -------------------------------------+------------------------------------- Reporter: So8res | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.4.1 Component: None | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Other | Blocked By: 5966 Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by god): Supporting XDG spec in the standard library is one thing but actually converting the ghc itself to use it is another. Those tasks are certainly related but I think it's worth to keep the corresponding bugs separate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 15:54:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 15:54:49 -0000 Subject: [GHC] #9531: Implement Prelude.Word Proposal In-Reply-To: <042.cd2d8918281e2e3dc04f053817312985@haskell.org> References: <042.cd2d8918281e2e3dc04f053817312985@haskell.org> Message-ID: <057.c14e3589434f9c635cfb56aa544b6258@haskell.org> #9531: Implement Prelude.Word Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Prelude Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"c9c20d477088a8a7d5747f16afdf0652fba6dadf/nofib"]: {{{ #!CommitTicketReference repository="nofib" revision="c9c20d477088a8a7d5747f16afdf0652fba6dadf" Hide Word from Prelude in benchmarks where Word is used. This fixes fall-out from #9531. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 15:56:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 15:56:58 -0000 Subject: [GHC] #9531: Implement Prelude.Word Proposal In-Reply-To: <042.cd2d8918281e2e3dc04f053817312985@haskell.org> References: <042.cd2d8918281e2e3dc04f053817312985@haskell.org> Message-ID: <057.4e5a9ae14fd93753675bf76c92d1c1a5@haskell.org> #9531: Implement Prelude.Word Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Prelude Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"1719c4207386a42ba4af9914340a6fe60045efe5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1719c4207386a42ba4af9914340a6fe60045efe5" Update nofib submodule: Hide Word from Prelude in benchmarks where Word is used. This fixes fall-out from #9531. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 15:59:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 15:59:03 -0000 Subject: [GHC] #9542: GHC-IO-Handle-Text.hPutStr' and writeBlocks look like they need refactoring In-Reply-To: <045.245970e68839d437b57a6968a4cc5957@haskell.org> References: <045.245970e68839d437b57a6968a4cc5957@haskell.org> Message-ID: <060.b04f749e536648c6234aa6ff4cda9b5e@haskell.org> #9542: GHC-IO-Handle-Text.hPutStr' and writeBlocks look like they need refactoring -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): There are probably actually some list fusion opportunities in this area these days. `hPutChars` is apparently low-performance anyway, but I think it might as well be written {{{#!hs hPutChars :: Handle -> [Char] -> IO () hPutChars handle = mapM_ (hPutChar handle) }}} More importantly, I would conjecture that we can probably fuse `writeBlocks`. Call Arity seems to allow a fusing `foldM`, and `writeBlocks` seems to have that general structure. The devil may have details, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 18:05:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 18:05:46 -0000 Subject: [GHC] #9542: GHC-IO-Handle-Text.hPutStr' and writeBlocks look like they need refactoring In-Reply-To: <045.245970e68839d437b57a6968a4cc5957@haskell.org> References: <045.245970e68839d437b57a6968a4cc5957@haskell.org> Message-ID: <060.c5674917455661cb08ba6d3ae84b556a@haskell.org> #9542: GHC-IO-Handle-Text.hPutStr' and writeBlocks look like they need refactoring -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: fusion, Resolution: | refactoring Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * keywords: => fusion, refactoring Comment: Indeed, `writeBlocks` ''can'' be written as a `foldM` form, which can fuse, at least in theory. It may, however, be a challenge to bend arity analysis to my will without inlining more than we should. This may or may not be compounded by the fact that in tearing apart `writeBlocks` I realized that there's a special case buried within: block buffering with normal (non-Windows) end-of-line conventions never actually needs to examine the characters it handles. I would venture to guess that we could exploit that fact to improve efficiency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 20:27:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 20:27:16 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.efe07025743255319b2b3b6e3b4c6a75@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1241, #2247, None/Unknown | #8356, #9103, #9227 Test Case: | Blocking: | Differential Revisions: Phab:D69 | -------------------------------------+------------------------------------- Comment (by neo): Hi! I'm not sure if I face the same problem as the issue author or if my code is just "wrong" but when testing my code with GHC 7.8 I get the [https://travis-ci.org/adp-multi/adp-multi/jobs/34132805#L437 same error] while it worked with 7.6. My library ([https://hackage.haskell.org/package /adp-multi adp-multi]) is a parsing library for running dynamic programming algorithms with sequences as input (used in bioinformatics to fold RNA secondary structures). The grammar is defined as a DSL where some syntax sugar is defined using type class instances. One of the two problematic instances is the following (simplified): {{{ {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE DeriveDataTypeable #-} -- | To support higher dimensions, a subword is a list -- of indices. Valid list lengths are 2n with n>0. type Subword = [Int] type Parser a b = Array Int a -- ^ The input sequence -> Subword -- ^ Subword of the input sequence to be parsed -> [b] -- ^ Parsing results class Parseable p a b | p -> a b where toParser :: p -> Parser a b data EPS = EPS deriving (Eq, Show, Data, Typeable) empty1 :: Parser a EPS empty1 _ [i,j] = [ EPS | i == j ] instance Parseable EPS a EPS where toParser _ = empty1 }}} See [https://github.com/adp-multi/adp- multi/blob/0.2.3/src/ADP/Multi/ElementaryParsers.hs#L152 here] and [https://github.com/adp-multi/adp-multi/blob/0.2.3/src/ADP/Multi/Parser.hs here] for the full code. The error with 7.8 is: {{{ Illegal instance declaration for ?Parseable EPS a EPS? The liberal coverage condition fails in class ?Parseable? for functional dependency: ?p -> a b? Reason: lhs type ?EPS? does not determine rhs types ?a?, ?EPS? In the instance declaration for ?Parseable EPS a EPS? }}} The other problematic instance is basically the same but for 2D inputs. In essence I want the empty word parser empty1 to work for any input type, e.g. for a char but also a number (which would then be a list of chars or numbers as the input sequence). Am I doing something terribly wrong or does this ticket also apply to me? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 07:21:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 07:21:17 -0000 Subject: [GHC] #8052: make ghci look for the files made by -dynamic-too In-Reply-To: <046.ee22f2889d89ec48dc121179c565ce39@haskell.org> References: <046.ee22f2889d89ec48dc121179c565ce39@haskell.org> Message-ID: <061.57f93a030c637ce516228cf006090f37@haskell.org> #8052: make ghci look for the files made by -dynamic-too -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.7 Component: GHCi | Keywords: Resolution: duplicate | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Yes thanks; fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 07:28:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 07:28:33 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.9ad67eff5bef16b686a2ec791046801a@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): I agree that byte-identical build results might be useful (though difficult), I question whether you need it for ccache. ccache doesn't need to compare build results, only build *inputs*; when the inputs are the same we can re-use the previous output. It doesn't matter whether repeating the build would produce the exact same output, only that it is valid to re-use the previous output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 07:29:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 07:29:53 -0000 Subject: [GHC] #9519: Add a way to mask thread preemption via fired timer for a computation In-Reply-To: <047.26171a8aa89618b26a4ae216870ee32e@haskell.org> References: <047.26171a8aa89618b26a4ae216870ee32e@haskell.org> Message-ID: <062.021b380ecc9e946d04c0624d4927f0f9@haskell.org> #9519: Add a way to mask thread preemption via fired timer for a computation -------------------------------------+------------------------------------- Reporter: abbradar | Owner: simonmar Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: infoneeded => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 07:56:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 07:56:59 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.170ae9298fc94cf9ac1759693116704f@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): I agree that the memo table implementation is relying in a very delicate way on a particular order of evaluation, so I'd be fine with using an explicit `lazy` in the implementation of memo and removing it from `unsafeDupablePerformIO`. If you want to do this and all the tests pass, it's fine by me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 09:11:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 09:11:37 -0000 Subject: [GHC] #9543: Testsuite driver: replace "extra_clean" by "git clean -X" Message-ID: <045.2f69795abaf71b802d453cc5970d5177@haskell.org> #9543: Testsuite driver: replace "extra_clean" by "git clean -X" -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When adding a new test that creates extra files, one also has to do some bookkeeping: 1. Supply an `extra_clean` argument to the test function in `all.T`. 2. Add an entry in `testsuite/.gitignore` Step number 1 is often forgotten. Currently there are over 200 uncleaned files and directories left behind in the `testsuite`, after running `validate` and then `make clean` (checked with `git clean -X -d -n | wc -l`). I propose to replace the functionality that `extra_clean` provides, namely to remove these extra files when one calls `make clean`, by doing the equivalent of `git clean -X -d`: {{{ -X Remove only files ignored by Git. -d Remove untracked directories in addition to untracked files. ... }}} That is: use the information from the `.ignore` files to figure out which files to delete on `make clean`. The advantages of making this change are: 1. Less manual bookkeeping, less work, less code 2. A more thorough `make clean` Implementation detail: we can not just call `git clean` directly, since this should also work when we are not in a git directory (for example a build directory created with [wiki:Building/Using lndir]). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 10:12:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 10:12:38 -0000 Subject: [GHC] #9481: Linker does not correctly resolve symbols in previously loaded objects In-Reply-To: <044.0f3c08e0d5a42fe8ecdcbe7daafad442@haskell.org> References: <044.0f3c08e0d5a42fe8ecdcbe7daafad442@haskell.org> Message-ID: <059.965f87949483488f82a7ec2aa99830c6@haskell.org> #9481: Linker does not correctly resolve symbols in previously loaded objects -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Works for me on Linux x86_64... somewhat surprisingly, since after `resolveObjs` has already failed once it seems likely that things might be left in a partially-linked state, and repeating `resolveObjs` might not work. I think after `resolveObjs` has failed you probably shouldn't use the linker any more and should report the error and exit, which is what GHCi does. What is the use case for retrying `resolveObjs` after it has failed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 10:46:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 10:46:22 -0000 Subject: [GHC] #8790: rts: unrust 'libbfd' debug symbols parser In-Reply-To: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> References: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> Message-ID: <060.4dfb9901b5dbde4655158f4932bb7866@haskell.org> #8790: rts: unrust 'libbfd' debug symbols parser -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: D193 | -------------------------------------+------------------------------------- Changes (by slyfox): * differential: => D193 Comment: Added manual knob, but did not fix that one-time leak: https://phabricator.haskell.org/D193 I propose to fix leak as another changeset with support for dynamic libs symbol loading. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 15:20:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 15:20:09 -0000 Subject: [GHC] #9544: No error message in explicit import containing unused and undefined constructor (Regression) Message-ID: <047.b695be6fc6060f76555ccf9378c1c65e@haskell.org> #9544: No error message in explicit import containing unused and undefined constructor (Regression) -------------------------------------+------------------------------------- Reporter: bergmark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | accepts invalid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Helper file: {{{#!hs module A where data X = Foo }}} Reproduction: {{{#!hs module B where import A (X (X)) f :: X f = undefined }}} Result (GHC 7.8.3): {{{ $ ghc -Wall B.hs [1 of 2] Compiling A ( A.hs, nothing ) [2 of 2] Compiling B ( B.hs, nothing ) $ }}} Result (GHC 7.6.3): {{{ $ ghc -Wall B.hs [1 of 2] Compiling A ( A.hs, nothing ) [2 of 2] Compiling B ( B.hs, nothing ) B.hs:3:11: Module `A' does not export `X(X)' $ }}} I tested other combinations and this regression seems to only occur when using an explicit import list and specifying an undefined constructor with the same name as the type. If you try to use the undefined constructor you will get an error at the use site instead of the import site. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 17:49:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 17:49:17 -0000 Subject: [GHC] #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build Message-ID: <045.67b198827318e5a03441f1825701405b@haskell.org> #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more | Type of failure: than a week) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Takano Akio's [https://github.com/takano-akio/ww-fusion worker-wrapper fusion] modifies `foldr/build` fairly conservatively to allow safe fusion of `foldl` and friends without relying on arity analysis. This advantage is important for two reasons that I know of: 1. As discussed in Joachim Breitner's original paper, the current arity analysis is unable to infer arity correctly when facing certain forms of recursion. 2. The current arity analysis, and probably ''any'' practical arity analysis, depends on inlining to a degree that can sometimes be unhealthy. I would love to make functions like `hPutStr` fuse, but I suspect doing so safely at present would likely cause a code explosion?the function being folded is too large to want to inline to make it available for arity analysis following fusion. I don't understand it completely yet, but it looks like `foldrW/buildW` can eliminate a lot of this uncertainty. Furthermore, it appears that functions currently written using `foldr` in a "right-handed" way can remain unchanged, using an implementation of `foldr` in terms of `foldrW`. Only "left-handed" folds will need to be rewritten to take advantage of this framework, along with all the `build`s. That said, `foldrW/buildW` probably has its weaknesses too. The basic fusion rule looks like this. {{{#!hs {-# RULES "foldrW/buildW" forall f z (i :: Wrap f b) (g :: forall c g . (Wrap g c) -> (a -> c -> c) -> c -> c) . foldrW i f z (buildW g) = g i f z #-} }}} If `g` and `i` are not inlined sufficiently to merge with each other, I imagine this could produce worse results than `foldr/build` when the latter works properly. The only way to really get a feel for performance would be to carefully modify everything to work as well as it can with this framework and see how the results compare. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 18:06:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 18:06:45 -0000 Subject: [GHC] #9546: filterM is not a good consumer for list fusion Message-ID: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> #9546: filterM is not a good consumer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This one shouldn't cause any wonkiness; it just updates `filterM` to fuse is much the same way `mapM` does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 18:07:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 18:07:28 -0000 Subject: [GHC] #9546: filterM is not a good consumer for list fusion In-Reply-To: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> References: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> Message-ID: <060.033703788f85978c8b66d213f87780a4@haskell.org> #9546: filterM is not a good consumer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 19:54:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 19:54:10 -0000 Subject: [GHC] #9546: filterM is not a good consumer for list fusion In-Reply-To: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> References: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> Message-ID: <060.359821cbf38eef52bf64811d16363f96@haskell.org> #9546: filterM is not a good consumer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): LGTM. (I?m a bit doubtful about `INLINE`ing such a rather large function, but `mapM` and `sequence` are also `INLINE`, so if it is ok for them, I guess it ought to be ok for this). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 21:22:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 21:22:20 -0000 Subject: [GHC] #9006: GHC accepts import of private data constructor if it has the same name as the type In-Reply-To: <046.f4fcc91a133451d6f840223341c96eb9@haskell.org> References: <046.f4fcc91a133451d6f840223341c96eb9@haskell.org> Message-ID: <061.e0ff433c6354221307c01cbf81282ac1@haskell.org> #9006: GHC accepts import of private data constructor if it has the same name as the type -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | rename/should_fail/T9006 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => merge Comment: I don't think this ever got merged, and it showed up again as #9544 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 21:23:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 21:23:25 -0000 Subject: [GHC] #9544: No error message in explicit import containing unused and undefined constructor (Regression) In-Reply-To: <047.b695be6fc6060f76555ccf9378c1c65e@haskell.org> References: <047.b695be6fc6060f76555ccf9378c1c65e@haskell.org> Message-ID: <062.217b36e8ac95004482ee4c01dd29c090@haskell.org> #9544: No error message in explicit import containing unused and undefined constructor (Regression) -------------------------------------+------------------------------------- Reporter: bergmark | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: Thank you. Happily, it's a dup of #9006, which has already been fixed. Although alas not merged into 7.8.3. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 3 21:31:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Sep 2014 21:31:00 -0000 Subject: [GHC] #9547: Empty constraint tuples are mis-kinded Message-ID: <046.4a68986f8009faa587ff75cd38e6aeac@haskell.org> #9547: Empty constraint tuples are mis-kinded -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider {{{ -- If :: forall k. 'Bool -> k -> k -> k type family If cond tru fls where If True tru fls = tru If False tru fls = fls foo :: If True () (Eq a) => a -> a foo = error "urk" }}} This should work fine. But we get {{{ Foo.hs:8:21: The third argument of `If' should have kind `*', but `Eq a' has kind `Constraint' In the type signature for `foo': foo :: If True () (Eq a) => a -> a }}} Reason: GHC is treating the `()` unit tuple as of kind `*`. Reason is that in the `HsTupleTy` case of `tc_hs_type` in `TcHsType`, we see {{{ -- In the [] case, it's not clear what the kind is, so guess * }}} And that guess is plain wrong in this case. Unfortunately I don't see an easy fix, but it's plain wrong as-is. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 02:06:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 02:06:50 -0000 Subject: [GHC] #9548: Numerical type system problem Message-ID: <046.fae0a8ad723b7ad17d1f6638edfb3c08@haskell.org> #9548: Numerical type system problem -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: Number | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Originally, in haskell 98 the factorial function {{{#!hs f 0 = 1 f n = n * f (n - 1) }}} has type Num a => a -> a, while after ghc 7.4 it requires Eq type class. I suggest that Num type class should be redefined as {{{#!hs class Eq a => Num a where ... }}} Since all the numbers are equality checkable. we can be more aggressive to have Order super class for numbers even complex numbers are not well ordered. I suppose that this is like the historical problem like Applicative should be the super class of Monad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 02:50:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 02:50:02 -0000 Subject: [GHC] #9548: Numerical type system problem In-Reply-To: <046.fae0a8ad723b7ad17d1f6638edfb3c08@haskell.org> References: <046.fae0a8ad723b7ad17d1f6638edfb3c08@haskell.org> Message-ID: <061.a9f990beb1b12eb23a3db8b42ef7a945@haskell.org> #9548: Numerical type system problem -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: | Keywords: Number libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): All numbers do not have a decidable notion of equality. {{{ instance Num b => Num (a -> b) }}} is the most common example, but computable reals and purely symbolic numeric types are other counter examples. GHC 7.4 deliberately made a breaking change away from the Haskell 98 standard to avoid forcing users to lie about equalities that couldn't exist. Going back on that decision would be a mistake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 02:54:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 02:54:47 -0000 Subject: [GHC] #9549: deriveConstants fails on OpenBSD Message-ID: <045.280f1382fe569e58794f97c954f259a6@haskell.org> #9549: deriveConstants fails on OpenBSD -------------------------------------+------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: OpenBSD Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- On OpenBSD 5.5 compilation of current HEAD fails with: {{{ inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "/usr/bin/gcc" --gcc-flag -fno- stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc- flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist- ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/bin/nm" nm: unknown option -- P usage: nm [-aCegnoprsuw] [file ...] deriveConstants: readProcess: /usr/bin/nm "-P" "includes/dist- derivedconstants/header/tmp.o" (exit 1): failed includes/ghc.mk:167: recipe for target 'includes/dist- derivedconstants/header/DerivedConstants.h' failed gmake[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 Makefile:71: recipe for target 'all' failed gmake: *** [all] Error 2 }}} This is due to OpenBSD's nm not supporting the -P option. Perhaps it can be fixed by using 'objdump --syms' instead of 'nm -P' (see attached OpenBSD-only patch). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 02:59:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 02:59:33 -0000 Subject: [GHC] #9548: Numerical type system problem In-Reply-To: <046.fae0a8ad723b7ad17d1f6638edfb3c08@haskell.org> References: <046.fae0a8ad723b7ad17d1f6638edfb3c08@haskell.org> Message-ID: <061.bfe1b599a7a34032839c16dab2657b78@haskell.org> #9548: Numerical type system problem -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: | Keywords: Number libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dolio): I'm in the same camp as ekmett. Some numeric types do not have decidable equality, and the current state of affairs is not a mistake (or at least, is less mistaken than the old one). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 03:02:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 03:02:36 -0000 Subject: [GHC] #9548: Numerical type system problem In-Reply-To: <046.fae0a8ad723b7ad17d1f6638edfb3c08@haskell.org> References: <046.fae0a8ad723b7ad17d1f6638edfb3c08@haskell.org> Message-ID: <061.821c605d8dc01b7e53528c74ef65dc34@haskell.org> #9548: Numerical type system problem -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: feature | Status: closed request | Milestone: Priority: lowest | Version: 7.8.3 Component: | Keywords: Number libraries/base | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * priority: normal => lowest * difficulty: Unknown => Easy (less than 1 hour) * status: new => closed * resolution: => wontfix * failure: None/Unknown => GHC rejects valid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 04:10:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 04:10:44 -0000 Subject: [GHC] #9550: Add uncons to Data.List Message-ID: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> #9550: Add uncons to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This was discussed on the libraries list and favorably received -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 04:12:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 04:12:22 -0000 Subject: [GHC] #9550: Add uncons to Data.List In-Reply-To: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> References: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> Message-ID: <060.f634e70aef52d966d0deeb7f15ad2247@haskell.org> #9550: Add uncons to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 04:16:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 04:16:44 -0000 Subject: [GHC] #9550: Add uncons to Data.List In-Reply-To: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> References: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> Message-ID: <060.8f630a2320e87b4b4272fccf0ca4e052@haskell.org> #9550: Add uncons to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * difficulty: Unknown => Easy (less than 1 hour) * type: task => feature request Comment: There were no objections on the list and positive noises from the committee. It looks good to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 08:35:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 08:35:32 -0000 Subject: [GHC] #9550: Add uncons to Data.List In-Reply-To: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> References: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> Message-ID: <060.3c9a711f4b8e700d83694bd9e52ffd00@haskell.org> #9550: Add uncons to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"e428b5b8cc1448dcff7d7cdcbeb738eb0bea102f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e428b5b8cc1448dcff7d7cdcbeb738eb0bea102f" Add Data.List.uncons Summary: As discussed in http://www.haskell.org/pipermail/libraries/2014-July/023314.html and submitted at #9550. Test Plan: Submit to phab, see what happens. Reviewers: austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D195 GHC Trac Issues: #9550 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 08:36:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 08:36:58 -0000 Subject: [GHC] #9551: Remove max_bytes_used from haddock tests Message-ID: <046.b61a435bcd519542daf017d18dffd5cc@haskell.org> #9551: Remove max_bytes_used from haddock tests -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Simon M says: ?I think we should probably remove the max_bytes_used limits for the Haddock tests.? (I plan to ?fix? this in the HIW contributors talk, so please do _not_ fix it just now :-). And sorry for the noise...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 08:40:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 08:40:44 -0000 Subject: [GHC] #9551: Remove max_bytes_used from haddock tests In-Reply-To: <046.b61a435bcd519542daf017d18dffd5cc@haskell.org> References: <046.b61a435bcd519542daf017d18dffd5cc@haskell.org> Message-ID: <061.0278f37a891db9c94f1dddcb33ab997c@haskell.org> #9551: Remove max_bytes_used from haddock tests -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: => nomeata -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 08:51:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 08:51:29 -0000 Subject: [GHC] #9551: Remove max_bytes_used from haddock tests In-Reply-To: <046.b61a435bcd519542daf017d18dffd5cc@haskell.org> References: <046.b61a435bcd519542daf017d18dffd5cc@haskell.org> Message-ID: <061.2cc41395b15e7fdff988609ddcc1888c@haskell.org> #9551: Remove max_bytes_used from haddock tests -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D196 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => D196 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 08:52:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 08:52:33 -0000 Subject: [GHC] #9551: Remove max_bytes_used from haddock tests In-Reply-To: <046.b61a435bcd519542daf017d18dffd5cc@haskell.org> References: <046.b61a435bcd519542daf017d18dffd5cc@haskell.org> Message-ID: <061.f95887400699f84734dbc633e6b7c20e@haskell.org> #9551: Remove max_bytes_used from haddock tests -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D196 | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"498d7dd2dc731a92eda2210e4ab0a04366511627/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="498d7dd2dc731a92eda2210e4ab0a04366511627" Do not test max_bytes_used et. al for haddock tests Summary: as these are unreliable, and it is hard to re-run haddock with other RTS flags. Test Plan: run validate Reviewers: austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D196 GHC Trac Issues: #9551 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 08:53:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 08:53:35 -0000 Subject: [GHC] #9551: Remove max_bytes_used from haddock tests In-Reply-To: <046.b61a435bcd519542daf017d18dffd5cc@haskell.org> References: <046.b61a435bcd519542daf017d18dffd5cc@haskell.org> Message-ID: <061.58eb1e8eb5871670f613d0a8c1d62d7c@haskell.org> #9551: Remove max_bytes_used from haddock tests -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D196 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 10:01:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 10:01:41 -0000 Subject: [GHC] #9550: Add uncons to Data.List In-Reply-To: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> References: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> Message-ID: <060.c824787d3b3b14f5cd0b649f0cfdcfb3@haskell.org> #9550: Add uncons to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D195 | -------------------------------------+------------------------------------- Changes (by hvr): * differential: => Phab:D195 * milestone: => 7.10.1 Old description: > This was discussed on the libraries list and favorably received New description: This was [http://www.haskell.org/pipermail/libraries/2014-July/023314.html discussed on the libraries list] and favourably received -- Comment: next time: please add links to Phab and mailing list in the ticket- metadata straightaway (as I would have had one minor complaint for the code-revision) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 10:44:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 10:44:48 -0000 Subject: [GHC] #9550: Add uncons to Data.List In-Reply-To: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> References: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> Message-ID: <060.351aa318ebb703e151900f5079c8586c@haskell.org> #9550: Add uncons to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D195 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"6af1c9b2709281520c2015349e4a15265c364962/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6af1c9b2709281520c2015349e4a15265c364962" Add missing changelog/since entry for `uncons` This is a follow-up commit to e428b5b8cc1448dcff7d7cdcbeb738eb0bea102f (refs D195 & #9550) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 11:17:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 11:17:17 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.f480d9c405df793d5e4abe20cf37e674@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by edsko): * cc: edsko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 11:17:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 11:17:43 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.b030bbe87c6e3fdd4d7769e6e02505ec@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by edsko): * cc: edsko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 14:35:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 14:35:46 -0000 Subject: [GHC] #8849: Unregisterised compiler: arithmetic failure In-Reply-To: <047.9ee4d36bdad2511c808fcc03f7b6b140@haskell.org> References: <047.9ee4d36bdad2511c808fcc03f7b6b140@haskell.org> Message-ID: <062.e5234dc7cdda7abb6c6b69fdf1500075@haskell.org> #8849: Unregisterised compiler: arithmetic failure -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: arith005 | Related Tickets: #8819 Blocking: 8819 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => merge Comment: The following commit fixes the bug: https://phabricator.haskell.org/rGHC43f1b2ecd1960fa7377cf55a2b97c66059a701ef -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 14:48:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 14:48:38 -0000 Subject: [GHC] #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date Message-ID: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date ----------------------------+---------------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Other | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+---------------------------------------------- Building ghc for powerpc64 little endian (powerpc64le) on Linux fails: {{{ inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Redundant modules: Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 FastBool Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream compiler/ghc.mk:640: recipe for target 'compiler/stage2/dll-split.stamp' failed }}} The same build, however, works for big endian powerpc64 which is also an unregisterised build via C code. Both builds were done with `GHC_DYNAMIC_PROGRAMS=YES` in `mk/build.mk`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 19:31:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 19:31:11 -0000 Subject: [GHC] #9553: GHC under Windows with TH can't tell that gtk-win32-2.0 is in gtk-win32-2.0-0 (note the -0 suffix) Message-ID: <054.38a60811fe28445b61888d4251c31be6@haskell.org> #9553: GHC under Windows with TH can't tell that gtk-win32-2.0 is in gtk- win32-2.0-0 (note the -0 suffix) -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: #5289 #1883 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following compilation under Wine (after applying the workarounds described at http://www.haskell.org/haskellwiki/GHC_under_Wine#Code_that_uses_gtk2hs) {{{ cabal install LambdaHack-0.4.99.0 }}} fails with (the full log attached) {{{ Loading package LambdaHack-0.4.99.1 ... ghc.exe: gtk-win32-2.0: Module not found. : can't load .so/.DLL for: gtk-win32-2.0.dll (addDLL: could not load DLL) }}} The following workaround sidesteps the problem, leading to a correctly running executable (symlinks are not enough). {{{ cp gtk/bin/libgtk-win32-2.0-0.dll gtk/bin/libgtk-win32-2.0.dll cp gtk/bin/libgdk-win32-2.0-0.dll gtk/bin/libgdk-win32-2.0.dll cp gtk/bin/libatk-1.0-0.dll gtk/bin/libatk-1.0.dll cp gtk/bin/libgio-2.0-0.dll gtk/bin/libgio-2.0.dll cp gtk/bin/libgio-2.0-0.dll gtk/bin/pango- cp gtk/bin/libgio-2.0-0.dll gtk/bin/ cp gtk/bin/libpangowin32-1.0-0.dll gtk/bin/libpangowin32-1.0.dll cp gtk/bin/libpangocairo-1.0-0.dll gtk/bin/libpangocairo-1.0.dll cp gtk/bin/libgdk_pixbuf-2.0-0.dll gtk/bin/libgdk_pixbuf-2.0.dll cp gtk/bin/libpango-1.0-0.dll gtk/bin/libpango-1.0.dll cp gtk/bin/libcairo- gtk/bin/libcairo.dll cp gtk/bin/libcairo-2.dll gtk/bin/libcairo.dll cp gtk/bin/libgobject-2.0-0.dll gtk/bin/libgobject-2.0.dll cp gtk/bin/libgmodule-2.0-0.dll gtk/bin/libgmodule-2.0.dll cp gtk/bin/libgthread-2.0-0.dll gtk/bin/libgthread-2.0.dll cp gtk/bin/libglib-2.0-0.dll gtk/bin/libglib-2.0.dll cp gtk/bin/libfontconfig-1.dll gtk/bin/libfontconfig.dll }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 19:34:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 19:34:37 -0000 Subject: [GHC] #5289: Can't use ghci with a library linked against libstdc++ In-Reply-To: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> References: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> Message-ID: <057.5b2c52b3f2d0157622ce44fb4c09ef88@haskell.org> #5289: Can't use ghci with a library linked against libstdc++ -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Replying to [comment:48 MichalGajda]: > On Windows, this bug seems also to prevent linking libraries that depend on double-conversion and Template Haskell. Are the symptoms similar to #9553? Does a similar workaround work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 4 22:04:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Sep 2014 22:04:00 -0000 Subject: [GHC] #9550: Add uncons to Data.List In-Reply-To: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> References: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> Message-ID: <060.568768b3469bc00efbfcc7b81e72fdbb@haskell.org> #9550: Add uncons to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D195 | -------------------------------------+------------------------------------- Comment (by nomeata): Sorry, I think I didn?t actually mean to push it yet without someone accepting the Differential Revision; I guess there was branch confusion on my side. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 5 06:32:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Sep 2014 06:32:53 -0000 Subject: [GHC] #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build In-Reply-To: <045.67b198827318e5a03441f1825701405b@haskell.org> References: <045.67b198827318e5a03441f1825701405b@haskell.org> Message-ID: <060.6525c66fbde631b6586bbe84eefd3a91@haskell.org> #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): === Update === Takano Akio's draft implementation has one or a few saturation issues and missing pragmas that prevent some necessary inlining when the fusion pipeline is not "capped" with a `foldrW`. This seems easy to fix, and I have done so for `map`. Dan Doel recognized that `foldrW/buildW` fusion, applied to situations currently handled with `foldr/build`, tends to produce recursive forms that pass a static argument around and around without touching it. He discovered that a modified version of `buildW`, call it `buildWForgetful` for now, can be used instead of `buildW` when recursion defining the builder satisfies a simple condition common to many important examples. One serious difficulty in dealing with this framework is the difficulty of ''understanding'' it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 5 07:03:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Sep 2014 07:03:05 -0000 Subject: [GHC] #9449: GHC.Prim documentation says "Safe Inferred" In-Reply-To: <047.6ad8c2a212ab3e49ebf79357b664b6f9@haskell.org> References: <047.6ad8c2a212ab3e49ebf79357b664b6f9@haskell.org> Message-ID: <062.ac552f68c3c7f50e98ea385dd81205a0@haskell.org> #9449: GHC.Prim documentation says "Safe Inferred" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: | Version: 7.8.2 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D182 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 5 17:37:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Sep 2014 17:37:55 -0000 Subject: [GHC] #9555: internal error: ARR_WORDS object entered! In-Reply-To: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> References: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> Message-ID: <059.d7cdaa06083ee2f7298eb9a151d17b37@haskell.org> #9555: internal error: ARR_WORDS object entered! -------------------------------------+------------------------------------- Reporter: walck | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) Comment: I've tried 'cyclotomic-0.4.3' package and it does not seem to crash that easily. Which one do you try to use? May I ask you to post complete output of: {{{ ghc -v -e 'Data.Complex.Cyclotomic.goldenRatio' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 5 18:10:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Sep 2014 18:10:11 -0000 Subject: [GHC] #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date In-Reply-To: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> References: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> Message-ID: <062.188ff9d8e7a3b1e7fe98bf574c1e19fa@haskell.org> #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date ----------------------------------------------+--------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by slyfox): * cc: slyfox (added) Comment: If you still can reproduce it, may I ask you to attach the file compiler/stage2/build/.depend-v-dyn.haskell itself? It should be enough to reproduce the error on other hosts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 5 18:25:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Sep 2014 18:25:17 -0000 Subject: [GHC] #9554: Pathological type family turns type error into runtime loop (was: Pathological type family seems to violate FC operational semantics) In-Reply-To: <047.10c0d6cec996432d07767233097ef363@haskell.org> References: <047.10c0d6cec996432d07767233097ef363@haskell.org> Message-ID: <062.a1aad0bb5ed5fa97d0a3fd856ddeb6d1@haskell.org> #9554: Pathological type family turns type error into runtime loop -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Another look at this revealed it's not as bad as I thought: the `Show` instance for `Proxy` is ''lazy'' in its argument. So, `foo` was never being evaluated. But, consider this: {{{#!hs {-# LANGUAGE TypeFamilies, UndecidableInstances #-} import Data.Proxy type family F a where F a = F (F a) foo :: Proxy (F Bool) -> Proxy (F Int) foo x = x main = case foo Proxy of Proxy -> putStrLn "Made it!" }}} This ''does'' properly force `foo`, and the result is a runtime loop. The core is similar to that in the original post, in that it contains clearly looping coercions. This is bad: it means that `-XUndecidableInstances` allows programs to go wrong, contrary to my (and many others') assumptions about `-XUndecidableInstances`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 5 18:36:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Sep 2014 18:36:01 -0000 Subject: [GHC] #9369: Data.List.unfoldr does not fuse and is not inlined. In-Reply-To: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> References: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> Message-ID: <060.45e76aca0aabf8d724edba2e5a5ea0f1@haskell.org> #9369: Data.List.unfoldr does not fuse and is not inlined. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch Comment: This took long enough to work through. I decided in the end that we shouldn't use any rules whatsoever for `unfoldr`, but should instead just `INLINE` it. A detailed explanation of my reasoning is included in the patch, but it comes down to two things: 1. Concerns about rules inlining `unfoldr` too early, and 2. The importance of inlining `unfoldr` whether it fuses or not to optimize common uses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 5 20:15:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Sep 2014 20:15:40 -0000 Subject: [GHC] #9555: internal error: ARR_WORDS object entered! In-Reply-To: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> References: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> Message-ID: <059.e64c2443bed16211319abd308ab02e9d@haskell.org> #9555: internal error: ARR_WORDS object entered! -------------------------------------+------------------------------------- Reporter: walck | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by walck): {{{ $ ghc -v -e 'Data.Complex.Cyclotomic.goldenRatio' Glasgow Haskell Compiler, Version 7.8.3, stage 2 booted by GHC version 7.8.2 Using binary package database: /usr/local/lib/ghc-7.8.3/package.conf.d/package.cache Using binary package database: /home/walck/.ghc/x86_64-linux-7.8.3/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-954cb57749cf319beafdc89b3415422c wired-in package integer-gmp mapped to integer- gmp-0.5.1.0-d42e6a7874a019e6a0d1c7305ebc83c4 wired-in package base mapped to base-4.7.0.1-e4b74d27ad8c8987c63abc42a80e7335 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-3afdeeadb657091939ef0bfa600dc614 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: Loading package ghc-prim ... linking ... done. *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/local/lib/ghc-7.8.3/integer-gmp-0.5.1.0 --print-file-name libgmp.so Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package transformers-0.3.0.0 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package random-1.0.1.3 ... linking ... done. Loading package arithmoi-0.4.1.1 ... linking ... done. Loading package cyclotomic-0.4.3 ... linking ... done. : internal error: ARR_WORDS object entered! (GHC version 7.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 5 21:06:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Sep 2014 21:06:19 -0000 Subject: [GHC] #9556: Remove max_bytes_used from haddock tests Message-ID: <046.864083e699e11b2f59c22b3d918db694@haskell.org> #9556: Remove max_bytes_used from haddock tests -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Simon M says: ?I think we should probably remove the `max_bytes_used` limits for the Haddock tests.? This also includes `peak_megabytes_allocated`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 5 21:19:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Sep 2014 21:19:01 -0000 Subject: [GHC] #9555: internal error: ARR_WORDS object entered! In-Reply-To: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> References: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> Message-ID: <059.f2cda1db25d8fbda20225785c3c762be@haskell.org> #9555: internal error: ARR_WORDS object entered! -------------------------------------+------------------------------------- Reporter: walck | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): Can you tell a bit more about your environment? - what linux distribution is that - gcc version - glibc version - binutils version - 'ghc --info' output - was it manually built ghc or piched from haskell.org -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 5 21:34:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Sep 2014 21:34:18 -0000 Subject: [GHC] #9369: Data.List.unfoldr does not fuse and is not inlined. In-Reply-To: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> References: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> Message-ID: <060.e7f273abefb50490fd2b447cfc52cf9d@haskell.org> #9369: Data.List.unfoldr does not fuse and is not inlined. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D198 | -------------------------------------+------------------------------------- Changes (by nomeata): * differential: => Phab:D198 Comment: I?m convinced by the reasoning :-) I put it on phabricator (more practice with this tool for me,and we get a validate run for free). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 00:52:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 00:52:24 -0000 Subject: [GHC] #9555: internal error: ARR_WORDS object entered! In-Reply-To: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> References: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> Message-ID: <059.7d8ee92e4d35d67cb91ca619c32fbdbb@haskell.org> #9555: internal error: ARR_WORDS object entered! -------------------------------------+------------------------------------- Reporter: walck | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by walck): {{{ walck at X230:~/computer/haskell/ghc/bug9555$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 13.10 Release: 13.10 Codename: saucy walck at X230:~/computer/haskell/ghc/bug9555$ gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. walck at X230:~/computer/haskell/ghc/bug9555$ /lib/x86_64-linux-gnu/libc.so.6 GNU C Library (Ubuntu EGLIBC 2.17-93ubuntu4) stable release version 2.17, by Roland McGrath et al. Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.7.3. Compiled on a Linux 3.11.3 system on 2013-10-12. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: . walck at X230:~/computer/haskell/ghc/bug9555$ ld --version GNU ld (GNU Binutils for Ubuntu) 2.23.52.20130913 Copyright 2013 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public Licence version 3 or (at your option) a later version. This program has absolutely no warranty. walck at X230:~/computer/haskell/ghc/bug9555$ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional ") ,("ld command","/usr/bin/ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","/usr/bin/llc") ,("LLVM opt command","/usr/bin/opt") ,("Project version","7.8.3") ,("Booter version","7.8.2") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.8.3") ,("Global Package DB","/usr/local/lib/ghc-7.8.3/package.conf.d") ] It was built from source. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 07:25:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 07:25:47 -0000 Subject: [GHC] #9555: internal error: ARR_WORDS object entered! In-Reply-To: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> References: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> Message-ID: <059.b8b0524af108a18150ac6fdadafbe250@haskell.org> #9555: internal error: ARR_WORDS object entered! -------------------------------------+------------------------------------- Reporter: walck | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): Aha, those are mostly saucy toolchain except for booter ghc. Saucy's universe has '''Version: 7.6.3-4''' of it. I'll try to reproduce by building 7.8.3 from it. {{{ ,("Project version","7.8.3") ,("Booter version","7.8.2") }}} Where did 7.8.2 come from? Did you build it yourself or I could grab the same version from some ppa? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 08:16:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 08:16:55 -0000 Subject: [GHC] #9400: poor performance when compiling modules with many Text literals at -O1 In-Reply-To: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> References: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> Message-ID: <062.738a6a14ed05cd7cb117a3f4094ba80e@haskell.org> #9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: xnyhps Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9370 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by xnyhps): * owner: => xnyhps Comment: This looked like quite a simple bug I could work on, so I decided to have a look. * Removing the `lengthFS str == 1` case in `mkStringExprFS` does not appear to break anything. * I've managed to modify `CoreSubst.exprIsConApp_maybe` to split calls to `unpackCString#` or `unpackCStringUtf8#`. It'll also recognize when it's a single-character string and split it into `(':', [c, nil])`, to avoid ever creating calls to `unpackCString*# ""#`. Looking at the generated Core, I've verified that it now pushes `unpackCString*#` calls through `case`-statements. This means that, even at -O0: {{{ main = case "abc" of (x:xs) -> putStrLn xs }}} compiles to `main = System.IO.putStrLn GHC.CString.unpackCString# "bc"#` * I haven't timed it, but `src/Text/XmlHtml/HTML/Meta.hs` now compiles quickly and with only ~180MB RAM. * `unpackCString#` and `unpackCStringUtf8#` seem very similar, except that `unpackCStringUtf8#` parses UTF8. At least for `mkStringExprFS` it could work to only use `unpackCStringUtf8#`, with a slight run-time penalty (calling `leChar#` for each character in the string), but the only benefit would be making rewrite rules easier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 08:28:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 08:28:24 -0000 Subject: [GHC] #9400: poor performance when compiling modules with many Text literals at -O1 In-Reply-To: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> References: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> Message-ID: <062.c166eb44b675371f78a44e1e325a1f6b@haskell.org> #9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: xnyhps Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9370 Test Case: | Blocking: | Differential Revisions: Phab:D199 | -------------------------------------+------------------------------------- Changes (by xnyhps): * differential: => Phab:D199 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 10:07:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 10:07:59 -0000 Subject: [GHC] #9555: internal error: ARR_WORDS object entered! In-Reply-To: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> References: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> Message-ID: <059.3ae7b17507342238f123e44bd8d6d4cd@haskell.org> #9555: internal error: ARR_WORDS object entered! -------------------------------------+------------------------------------- Reporter: walck | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): I've managed to reproduce it! I think the problem arises due to '''arithmoi''' being alone package built with ghc -fllvm. It should not break, but llvm is a bit experimental target (maybe upgrading '''llvm''' version will help, dunno). To workaround it you can buiild arithmoi w/o llvm flag: {{{ cabal install cyclotomic arithmoi -f-llvm --reinstall }}} The steps to reproduce: {{{ # get saucy mkdir saucy debootstrap saucy saucy/ https://mirrors.kernel.org/ubuntu/ chroot saucy/ echo 'deb http://archive.ubuntu.com/ubuntu saucy main universe' > /etc/apt/sources.list apt-get update apt-get install ghc cabal-install ncurses-dev build-essential llvm # unpack ghc, ./configure && make # get latest cabal cabal update cabal install cabal-install # get arithmoi ~/.cabal/bin/cabal install --with-compiler=$(pwd)/inplace/bin/ghc- stage2 cyclotomic # reproduce root at sf:~/ghc-7.8.3# inplace/bin/ghc-stage2 -e 'Data.Complex.Cyclotomic.goldenRatio' : internal error: ARR_WORDS object entered! (GHC version 7.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 10:10:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 10:10:07 -0000 Subject: [GHC] #9556: Remove max_bytes_used from haddock tests In-Reply-To: <046.864083e699e11b2f59c22b3d918db694@haskell.org> References: <046.864083e699e11b2f59c22b3d918db694@haskell.org> Message-ID: <061.ae8254fec599351d1f982f816011378a@haskell.org> #9556: Remove max_bytes_used from haddock tests -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: => nomeata Comment: Yay, I?ll do that now! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 10:18:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 10:18:01 -0000 Subject: [GHC] #9556: Remove max_bytes_used from haddock tests In-Reply-To: <046.864083e699e11b2f59c22b3d918db694@haskell.org> References: <046.864083e699e11b2f59c22b3d918db694@haskell.org> Message-ID: <061.79b9d570769da322308319733e6b26b2@haskell.org> #9556: Remove max_bytes_used from haddock tests -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D200 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D200 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 10:22:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 10:22:47 -0000 Subject: [GHC] #9556: Remove max_bytes_used from haddock tests In-Reply-To: <046.864083e699e11b2f59c22b3d918db694@haskell.org> References: <046.864083e699e11b2f59c22b3d918db694@haskell.org> Message-ID: <061.8d122bb47db7147d8ed77630dcb402b1@haskell.org> #9556: Remove max_bytes_used from haddock tests -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D200 | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"7bf7ca2b7a0f5ccf379cc035ad1e8bd80ea045f8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7bf7ca2b7a0f5ccf379cc035ad1e8bd80ea045f8" Do not use max_bytes_used for haddock test Summary: as they are unreliable and hard to re-run. Test Plan: Run the testsuite Reviewers: austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D200 GHC Trac Issues: #9556 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 10:25:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 10:25:51 -0000 Subject: [GHC] #9556: Remove max_bytes_used from haddock tests In-Reply-To: <046.864083e699e11b2f59c22b3d918db694@haskell.org> References: <046.864083e699e11b2f59c22b3d918db694@haskell.org> Message-ID: <061.4c0c64a02d82733cfa67bbabdd766d46@haskell.org> #9556: Remove max_bytes_used from haddock tests -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D200 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 13:01:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 13:01:22 -0000 Subject: [GHC] #9557: Deriving instances is slow Message-ID: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Let's take [https://raw.githubusercontent.com/haskell-suite/haskell-src- exts/8e0153d33b66add96fd5606614ce7938d2029510/src/Language/Haskell/Exts/Annotated/Syntax.hs this file] (from haskell-src-exts) and build it with -O0. On my machine it takes 55s. If we remove deriving of all classes except Functor (which is the only one used by the module itself), the time will drop down to 4s. Different classes vary in their compile-time cost, but there's no single culprit. Among the costly ones are Generic, Data, Show, Ord. haskell-src-exts users are very annoyed by its long compile time, about 10 minutes, especially because we don't compile with -O0 by default. It would be nice to get this fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 15:25:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 15:25:13 -0000 Subject: [GHC] #9494: Probable data corruption with GHCi 7.8.* and Zlib In-Reply-To: <047.c599b15a57b1de1c882b98999535443e@haskell.org> References: <047.c599b15a57b1de1c882b98999535443e@haskell.org> Message-ID: <062.5f7f89e92c3935a17c9e76f8df9806ea@haskell.org> #9494: Probable data corruption with GHCi 7.8.* and Zlib -------------------------------------+------------------------------------- Reporter: nominolo | Owner: aseipp Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nominolo): * owner: => aseipp * priority: normal => high Comment: Austin, could you please try to reproduce this? It's a pretty scary bug and until we know the cause it should be high priority to figure out what else it may affect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 15:34:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 15:34:55 -0000 Subject: [GHC] #9494: Probable data corruption with GHCi 7.8.* and Zlib In-Reply-To: <047.c599b15a57b1de1c882b98999535443e@haskell.org> References: <047.c599b15a57b1de1c882b98999535443e@haskell.org> Message-ID: <062.ae521d3e8839cb3ddda12d75189d0102@haskell.org> #9494: Probable data corruption with GHCi 7.8.* and Zlib -------------------------------------+------------------------------------- Reporter: nominolo | Owner: aseipp Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): The zlib library internally uses a bunch of unsafe functions (`unsafePerformIO`, `unsafeForeignPtrToPtr`) so this is also quite possibly just a bug in zlib. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 15:40:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 15:40:26 -0000 Subject: [GHC] #9555: internal error: ARR_WORDS object entered! In-Reply-To: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> References: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> Message-ID: <059.24de0428fd2973450bb174ddd350b209@haskell.org> #9555: internal error: ARR_WORDS object entered! -------------------------------------+------------------------------------- Reporter: walck | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): So this is LLVM 3.2, I guess (http://packages.ubuntu.com/saucy/llvm)? There are known problems with LLVM 3.2 and GHC, can you try with 3.3 or 3.4? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 15:43:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 15:43:22 -0000 Subject: [GHC] #9558: "Illegal equational constraint" that might not be the users fault Message-ID: <047.9b1d3d881f2dea1952fccc5d58e63e62@haskell.org> #9558: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If you try the latest cabal head and GHC together as of 2014.09.04, and then you try to install statistics, you'll see an error like the following, which does not occur in GHC 7.8.3: {{{ cabal-1.21 install -w ghc-7.9.20140904 Resolving dependencies... Configuring statistics-0.13.2.1... Building statistics-0.13.2.1... Preprocessing library statistics-0.13.2.1... [ 1 of 46] Compiling Statistics.Test.Internal ( Statistics/Test/Internal.hs, dist/build/Statistics/Test/Internal.o ) [ 2 of 46] Compiling Statistics.Test.Types ( Statistics/Test/Types.hs, dist/build/Statistics/Test/Types.o ) [ 3 of 46] Compiling Statistics.Internal ( Statistics/Internal.hs, dist/build/Statistics/Internal.o ) [ 4 of 46] Compiling Statistics.Transform ( Statistics/Transform.hs, dist/build/Statistics/Transform.o ) Statistics/Transform.hs:113:3: Illegal equational constraint Control.Monad.Primitive.PrimState m ~ s (Use GADTs or TypeFamilies to permit this) When checking that ?bitReverse? has the inferred type bitReverse :: forall (m :: * -> *) b. (Control.Monad.Primitive.PrimMonad m, Control.Monad.Primitive.PrimState m ~ s) => Int -> Int -> m b In an equation for ?mfft?: }}} (Indeed, adding the GADTs language pragma makes the type checker happy, as in the commit here: https://github.com/rrnewton/criterion/commit/3a2487176e92b6972560ab1abdfa09a2b3eb4a49 ) Hmm, well, the source code in this case did not explicitly add the "~ s" constraint, the inference cooked it up. Is this a GHC bug in 7.9 or in 7.8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 15:44:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 15:44:24 -0000 Subject: [GHC] #9559: "Illegal equational constraint" that might not be the users fault Message-ID: <047.fdb9c54a06f2e7b9f635fd313e0cea86@haskell.org> #9559: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If you try the latest cabal head and GHC together as of 2014.09.04, and then you try to install statistics, you'll see an error like the following, which does not occur in GHC 7.8.3: {{{ cabal-1.21 install -w ghc-7.9.20140904 Resolving dependencies... Configuring statistics-0.13.2.1... Building statistics-0.13.2.1... Preprocessing library statistics-0.13.2.1... [ 1 of 46] Compiling Statistics.Test.Internal ( Statistics/Test/Internal.hs, dist/build/Statistics/Test/Internal.o ) [ 2 of 46] Compiling Statistics.Test.Types ( Statistics/Test/Types.hs, dist/build/Statistics/Test/Types.o ) [ 3 of 46] Compiling Statistics.Internal ( Statistics/Internal.hs, dist/build/Statistics/Internal.o ) [ 4 of 46] Compiling Statistics.Transform ( Statistics/Transform.hs, dist/build/Statistics/Transform.o ) Statistics/Transform.hs:113:3: Illegal equational constraint Control.Monad.Primitive.PrimState m ~ s (Use GADTs or TypeFamilies to permit this) When checking that ?bitReverse? has the inferred type bitReverse :: forall (m :: * -> *) b. (Control.Monad.Primitive.PrimMonad m, Control.Monad.Primitive.PrimState m ~ s) => Int -> Int -> m b In an equation for ?mfft?: }}} (Indeed, adding the GADTs language pragma makes the type checker happy, as in the commit here: https://github.com/rrnewton/criterion/commit/3a2487176e92b6972560ab1abdfa09a2b3eb4a49 ) Hmm, well, the source code in this case did not explicitly add the "~ s" constraint, the inference cooked it up. Is this a GHC bug in 7.9 or in 7.8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 15:51:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 15:51:24 -0000 Subject: [GHC] #9560: "Illegal equational constraint" that might not be the users fault Message-ID: <047.4b32a75218bc7c94ef91d174dc35c083@haskell.org> #9560: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If you try the latest cabal head and GHC together as of 2014.09.04, and then you try to install statistics, you'll see an error like the following, which does not occur in GHC 7.8.3: {{{ cabal-1.21 install -w ghc-7.9.20140904 Resolving dependencies... Configuring statistics-0.13.2.1... Building statistics-0.13.2.1... Preprocessing library statistics-0.13.2.1... [ 1 of 46] Compiling Statistics.Test.Internal ( Statistics/Test/Internal.hs, dist/build/Statistics/Test/Internal.o ) [ 2 of 46] Compiling Statistics.Test.Types ( Statistics/Test/Types.hs, dist/build/Statistics/Test/Types.o ) [ 3 of 46] Compiling Statistics.Internal ( Statistics/Internal.hs, dist/build/Statistics/Internal.o ) [ 4 of 46] Compiling Statistics.Transform ( Statistics/Transform.hs, dist/build/Statistics/Transform.o ) Statistics/Transform.hs:113:3: Illegal equational constraint Control.Monad.Primitive.PrimState m ~ s (Use GADTs or TypeFamilies to permit this) When checking that ?bitReverse? has the inferred type bitReverse :: forall (m :: * -> *) b. (Control.Monad.Primitive.PrimMonad m, Control.Monad.Primitive.PrimState m ~ s) => Int -> Int -> m b In an equation for ?mfft?: }}} (Indeed, adding the GADTs language pragma makes the type checker happy, as in the commit here: https://github.com/rrnewton/criterion/commit/3a2487176e92b6972560ab1abdfa09a2b3eb4a49 ) Hmm, well, the source code in this case did not explicitly add the "~ s" constraint, the inference cooked it up. Is this a GHC bug in 7.9 or in 7.8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 16:10:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 16:10:52 -0000 Subject: [GHC] #9494: Probable data corruption with GHCi 7.8.* and Zlib In-Reply-To: <047.c599b15a57b1de1c882b98999535443e@haskell.org> References: <047.c599b15a57b1de1c882b98999535443e@haskell.org> Message-ID: <062.d0e9a3bd753e60670b8c258764c529ff@haskell.org> #9494: Probable data corruption with GHCi 7.8.* and Zlib -------------------------------------+------------------------------------- Reporter: nominolo | Owner: aseipp Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): I reproduced this on GHC 7.8.3, Ubuntu 12.04.5 (the first of many different errors in consecutive runs): {{{ ThreadId 46:0x00007f05a6351010 *** Exception: Codec.Compression.Zlib: invalid stored block lengths }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 19:13:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 19:13:04 -0000 Subject: [GHC] #9561: Clean up mergeSATInfo Message-ID: <045.e75f4cf175b68122b78f890c1d8597ac@haskell.org> #9561: Clean up mergeSATInfo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `mergeSATInfo` in SAT.hs is much longer and harder to read than it needs to be. I am attaching a patch to make it use `zipWith` instead of zipping manually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 19:14:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 19:14:15 -0000 Subject: [GHC] #9561: Clean up mergeSATInfo In-Reply-To: <045.e75f4cf175b68122b78f890c1d8597ac@haskell.org> References: <045.e75f4cf175b68122b78f890c1d8597ac@haskell.org> Message-ID: <060.5b5e9b6c81782a767184598067bfcd7d@haskell.org> #9561: Clean up mergeSATInfo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 19:30:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 19:30:58 -0000 Subject: [GHC] #8701: Update libffi-tarballs to latest libffi In-Reply-To: <045.7220d8c135ec272812ad62a34a63cda9@haskell.org> References: <045.7220d8c135ec272812ad62a34a63cda9@haskell.org> Message-ID: <060.3b09a198cf35ac19c8da2603b23fb5f4@haskell.org> #8701: Update libffi-tarballs to latest libffi -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 (FFI) | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by angerman): According to the History at https://github.com/atgreen/libffi AArch64 (ARM) support was added in libffi 3.1 {{{ 3.1 May-19-14 Add AArch64 (ARM64) iOS support. Add Nios II support. Add m88k and DEC VAX support. Add support for stdcall, thiscall, and fastcall on non-Windows 32-bit x86 targets such as Linux. Various Android, MIPS N32, x86, FreeBSD and UltraSPARC IIi fixes. Make the testsuite more robust: eliminate several spurious failures, and respect the $CC and $CXX environment variables. Archive off the manually maintained ChangeLog in favor of git log. }}} The original libffi patch that is part of the libffi-3.0.14.tar.gz as mentioned above ended up in two pull requests: - https://github.com/atgreen/libffi/pull/19 - https://github.com/atgreen/libffi/pull/60 of which non was finally merged. Both seem dead by now, but as mentioned above in libffi 3.1, iOS support was added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 20:16:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 20:16:46 -0000 Subject: [GHC] #5797: readRawBufferPtr cannot be interrupted by exception on Windows with -threaded In-Reply-To: <048.3736f5643746a43df87c9b05401ef4e8@haskell.org> References: <048.3736f5643746a43df87c9b05401ef4e8@haskell.org> Message-ID: <063.65faccc0bd92f53f29de90b34ff0c0e4@haskell.org> #5797: readRawBufferPtr cannot be interrupted by exception on Windows with -threaded -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: | Version: 7.2.2 libraries/base | Keywords: Resolution: | Architecture: x86 Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ryan.gl.scott@?, hvr, ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 20:21:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 20:21:56 -0000 Subject: [GHC] #9369: Data.List.unfoldr does not fuse and is not inlined. In-Reply-To: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> References: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> Message-ID: <060.ac2fb45588eeb26aef9858801224ce2a@haskell.org> #9369: Data.List.unfoldr does not fuse and is not inlined. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D198 | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"78209d70596dcbfcb11ad1de1c961ab8479e531e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="78209d70596dcbfcb11ad1de1c961ab8479e531e" INLINE unfoldr Summary: to allow GHC to maybe remove the Maybe. See the code comment for more commentary. This fixes #9369. Test Plan: see what happens on ghcspeed (once it is merged) Reviewers: austin Reviewed By: austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D198 GHC Trac Issues: #9369 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 20:24:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 20:24:05 -0000 Subject: [GHC] #9369: Data.List.unfoldr does not fuse and is not inlined. In-Reply-To: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> References: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> Message-ID: <060.2fbe6c95794a2aad1b41d2057a27fc67@haskell.org> #9369: Data.List.unfoldr does not fuse and is not inlined. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D198 | -------------------------------------+------------------------------------- Comment (by nomeata): Pushed, thanks. Hmm, looks like I forgot to change the author to David. Sorry! I don?t even know how to do that with `arc land`. A pitty that either git knowledge or arc becomes less useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 20:24:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 20:24:27 -0000 Subject: [GHC] #9369: Data.List.unfoldr does not fuse and is not inlined. In-Reply-To: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> References: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> Message-ID: <060.561e2aa029ef1074edc52185a8a07bf8@haskell.org> #9369: Data.List.unfoldr does not fuse and is not inlined. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D198 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 21:24:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 21:24:09 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.093e6667e58cb6a537faf0a13915489b@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by mlen): * owner: jstolarek => mlen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 21:28:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 21:28:58 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.991e126fb80003fb5f865442a9b35a13@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mlen): I implemented this feature and a test case. Implementation took only few lines of code, but in order compile the compiler I needed to add quite a lot GHC_OPTIONS pragmas with -fno-warn-tabs (few git submodules were affected by this change). I have a week off and I won't have access to my computer, but I'll continue working on the patch when I get back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 6 23:58:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Sep 2014 23:58:21 -0000 Subject: [GHC] #9562: Type families + hs-boot files = unsafeCoerce Message-ID: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> #9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | accepts invalid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider the following bundle of modules: A.hs: {{{#!hs {-# LANGUAGE TypeFamilies #-} module A where type family F a b }}} B.hs-boot: {{{#!hs module B where import A oops :: F a b -> a -> b }}} B.hs: {{{#!hs {-# LANGUAGE TypeFamilies #-} module B where import A import C type instance F a b = b oops :: F a b -> a -> b oops = const }}} C.hs: {{{#!hs module C (oops) where import {-# SOURCE #-} B }}} D.hs: {{{#!hs {-# LANGUAGE TypeFamilies #-} module D where import A import C type instance F a b = a unsafeCoerce :: a -> b unsafeCoerce x = oops x x }}} Main.hs: {{{#!hs module Main where import D ( unsafeCoerce ) main = print $ (unsafeCoerce True :: Int) }}} When loading these into GHCi, we quite reasonably get a type family instance overlap error. But, separate compilation leads to disaster: {{{ rae:01:49:47 ~/temp/bug> ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 rae:01:49:49 ~/temp/bug> ghc -c A.hs rae:01:49:53 ~/temp/bug> ghc -c B.hs-boot rae:01:49:58 ~/temp/bug> ghc -c C.hs rae:01:50:09 ~/temp/bug> ghc -c B.hs rae:01:50:13 ~/temp/bug> ghc -c D.hs rae:01:50:17 ~/temp/bug> ghc Main.hs -o Unsafe [6 of 6] Compiling Main ( Main.hs, Main.o ) Linking Unsafe ... rae:01:50:23 ~/temp/bug> ./Unsafe 2882303761534249061 }}} Yikes! Proposed (terrible) solution: hs-boot files '''must''' list all type instance declarations in the corresponding modules. It may also be a good idea to require all normal instance declarations in the hs-boot file as well, because this same trick can be used to introduce incoherence (I think -- haven't tested). This bug persists even if `Main` declares that it is `Safe`. I've attached a tarball of the files for ease of testing. (Credit to Edward Yang and Geoff Mainland, whose discussion provoked the line of inquiry that led to this discovery.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 7 05:54:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Sep 2014 05:54:07 -0000 Subject: [GHC] #9562: Type families + hs-boot files = unsafeCoerce In-Reply-To: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> References: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> Message-ID: <062.00240f957d882d766334de192b27139a@haskell.org> #9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): Richard Eisenberg does it again! Ticket #9422 seems related. I support the proposed solution. (Note that the situation is different for module signatures ala #9252, because when we compile against a signature's hi file we can pull in the original implementation to get its type family instances for a consistency check.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 7 07:38:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Sep 2014 07:38:28 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.4ce799645a9b1c84d747d329cf8a9f0b@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Where can we see the patch? BTW. Thanks for taking over this. It slipped from my radar completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 7 08:27:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Sep 2014 08:27:55 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.ec0a22bc7596f191b4823c8f82d6a096@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mlen): The main patch can be found here: https://github.com/mlen/ghc/commit/62cd7b983aee6b581f42184fcc38b3d9bf50780e, while this commit includes only additions of -fno-warn-tabs: https://github.com/mlen/ghc/commit/1c60eaffe373bf6a6324d1a243130b9dbbf843b5 I still need to take care of submodules. libraries/{haskeline,hpc,stm,time,unix,xhtml} and utils/hsc2hs need to be patched because of -Werror. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 7 09:05:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Sep 2014 09:05:42 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.c0995915fa2a6e6f4d8701263e1e5a2e@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): I think it is a good idea to also add a comment that motivates to remove tabs when doing some major changes to the file. I think we could just reuse the comment used in GHC source code: {{{ {-# OPTIONS_GHC -fno-warn-tabs #-} -- The above warning supression flag is a temporary kludge. -- While working on this module you are encouraged to remove it and -- detab the module (please do the detabbing in a separate patch). See -- http://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle#TabsvsSpaces -- for details }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 7 09:54:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Sep 2014 09:54:50 -0000 Subject: [GHC] #9563: Support for deriving Generic1 for data families Message-ID: <047.5afce0493774ce2d5de4e9e316ca0dec@haskell.org> #9563: Support for deriving Generic1 for data families -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code: {{{#!hs import GHC.Generics data family F typ :: * -> * data A data instance F A a = AData a deriving Generic1 }}} produces an error when run with ghc 7.8.2 or 7.8.3: {{{ Couldn't match type ?Rep1 (F A)? with ?M1 t0 t1 (M1 t2 t3 (M1 t4 t5 Par1))? The type variables ?t0?, ?t1?, ?t2?, ?t3?, ?t4?, ?t5? are ambiguous Expected type: Rep1 (F A) a Actual type: M1 t0 t1 (M1 t2 t3 (M1 t4 t5 Par1)) a In the pattern: M1 (M1 (M1 g1)) In an equation for ?to1?: to1 (M1 (M1 (M1 g1))) = AData (unPar1 g1) In the instance declaration for ?Generic1 (F A)? }}} whereas ghc 7.6.3 simply refuses to go ahead with the message: {{{ generic1.hs:14:40: Derived instance `Generic1 (F A)' requires illegal partial application of data type family F In the data instance declaration for `F' }}} Either a check has gone missing in 7.8.x, or a bug has crept up in the Generic1 support. I have gone through past tickets and https://ghc.haskell.org/trac/ghc/ticket/5936 suggests that it is the latter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 7 10:46:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Sep 2014 10:46:08 -0000 Subject: [GHC] #9564: Floating point subnormals overrounded on output Message-ID: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> #9564: Floating point subnormals overrounded on output -------------------------------------+------------------------------------- Reporter: jrp | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following test suggests that GHC is overrounding Float subnormals, when printing them out {{{ Prelude> 2**(-149) 1.401298464324817e-45 Prelude> 2**(-149) :: Float 1.0e-45 Prelude> isDenormalized it True Prelude> Prelude> 2**(-149) * 2**(100) * 2**(49) :: Float 1.0 }}} By comparison {{{ #include #include int main (void) { float clang_dec, clang_hex, libc_dec, libc_hex; clang_dec = 1.401298464324817e-45; clang_hex = 0x0.000002P-126; printf("clang (from decimal) = %a\n",clang_dec); printf("clang (from decimal) = %g\n",clang_dec); printf("clang (from hex) = %a\n",clang_hex); printf("clang (from hex) = %g\n",clang_hex); libc_dec = strtod("1.401298464324817e-45",NULL); libc_hex = strtod("0x0.000002P-126",NULL); printf("libc (from decimal) = %a\n",libc_dec); printf("libc (from decimal) = %g\n",libc_dec); printf("libc (from hex) = %a\n",libc_hex); printf("libc (from hex) = %g\n",libc_hex); } }}} produces {{{ clang (from decimal) = 0x1p-149 clang (from decimal) = 1.4013e-45 clang (from hex) = 0x1p-149 clang (from hex) = 1.4013e-45 libc (from decimal) = 0x1p-149 libc (from decimal) = 1.4013e-45 libc (from hex) = 0x1p-149 libc (from hex) = 1.4013e-45 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 7 13:41:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Sep 2014 13:41:39 -0000 Subject: [GHC] #5395: Context reduction stack overflow without undecidable instances In-Reply-To: <044.cc587d7f60fab1552eaf50eae3520e7a@haskell.org> References: <044.cc587d7f60fab1552eaf50eae3520e7a@haskell.org> Message-ID: <059.34c68804c4b067a2aae056ae6ec9e35e@haskell.org> #5395: Context reduction stack overflow without undecidable instances -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 Resolution: | Keywords: type family, Operating System: | termination Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jystic): I just ran in to this problem using the protobuf library with GHC 7.8.3, it seems that the constant limit has been changed back to 20? Compiling with -fcontext-stack=37 solves the problem in my case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 7 15:03:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Sep 2014 15:03:10 -0000 Subject: [GHC] #9555: internal error: ARR_WORDS object entered! In-Reply-To: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> References: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> Message-ID: <059.650435059ca28dcddb5509240f6da450@haskell.org> #9555: internal error: ARR_WORDS object entered! -------------------------------------+------------------------------------- Reporter: walck | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Hmm, I couldn't reproduce the issue with LLVM 3.2 on Ubuntu LTS 12.04 using the 7.8.3 bindist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 7 15:30:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Sep 2014 15:30:17 -0000 Subject: [GHC] #9558: "Illegal equational constraint" that might not be the users fault In-Reply-To: <047.9b1d3d881f2dea1952fccc5d58e63e62@haskell.org> References: <047.9b1d3d881f2dea1952fccc5d58e63e62@haskell.org> Message-ID: <062.c7c6af3976e95762eb35a4862deb4b71@haskell.org> #9558: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): > Is this a GHC bug in 7.9 or in 7.8? Neither really, this is an intentional change in behavior, see #8883. (Though I personally question whether it is worth breaking existing code for a rather intangible benefit.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 7 17:22:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Sep 2014 17:22:07 -0000 Subject: [GHC] #7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 In-Reply-To: <049.1dc64d9da3fa936aad83b3c8f408b65e@haskell.org> References: <049.1dc64d9da3fa936aad83b3c8f408b65e@haskell.org> Message-ID: <064.0cb6ef0386b92f97f88764a3c4c05d56@haskell.org> #7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 -------------------------------------+------------------------------------- Reporter: tinctorius | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tinctorius): No problems with GHC HEAD. Consider it fixed :D -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 7 18:42:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Sep 2014 18:42:06 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.67ba2ad7dacfccb0d7acf8cd43ffa85a@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 7 19:05:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Sep 2014 19:05:51 -0000 Subject: [GHC] #7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 In-Reply-To: <049.1dc64d9da3fa936aad83b3c8f408b65e@haskell.org> References: <049.1dc64d9da3fa936aad83b3c8f408b65e@haskell.org> Message-ID: <064.ff015a75442c60d2d5d155399c0d42b2@haskell.org> #7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 -------------------------------------+------------------------------------- Reporter: tinctorius | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 7 19:06:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Sep 2014 19:06:07 -0000 Subject: [GHC] #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date In-Reply-To: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> References: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> Message-ID: <062.556bca05dc2006aa962e983f09a30ef8@haskell.org> #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date ----------------------------------------------+--------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by slyfox): Did you happen to disable ghci building on that platform or maybe you've noticed it was not enabled there (it should)? Otherwise make does not generate a few of depends it relies on as required like this one: {{{ compiler/stage2/build/ByteCodeGen.dyn_o : compiler/stage2/build/Bitmap.dyn_hi compiler/stage2/build/ByteCodeGen.o : compiler/stage2/build/Bitmap.hi }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 8 05:49:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Sep 2014 05:49:53 -0000 Subject: [GHC] #9564: Floating point subnormals overrounded on output In-Reply-To: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> References: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> Message-ID: <057.50ace55213ccfa14598c11bc787b3682@haskell.org> #9564: Floating point subnormals overrounded on output -------------------------------------+------------------------------------- Reporter: jrp | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Overrounding in what sense? Do we have a spec for the Show Float, Show Double instances? (Honest question.) I thought that we tried to show the fewest number of significant figures that would round unambiguously to the true value of the floating-point number (which is `1.40129846432481707092372958328991613128026194187651577175706828388979108268586060148663818836212158203125e-45` in this case). In that case `1.0e-45` would be correct since `1.401...e-45` is the smallest positive Float and `1.0e-45` is more than half of it. However, I don't recall where I got that impression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 8 06:34:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Sep 2014 06:34:04 -0000 Subject: [GHC] #8701: Update libffi-tarballs to latest libffi In-Reply-To: <045.7220d8c135ec272812ad62a34a63cda9@haskell.org> References: <045.7220d8c135ec272812ad62a34a63cda9@haskell.org> Message-ID: <060.18bc9988b87134a038e10a38a791c5f3@haskell.org> #8701: Update libffi-tarballs to latest libffi -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1-rc1 (FFI) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by angerman): * status: closed => new * resolution: invalid => * milestone: 7.8.1 => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 8 10:13:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Sep 2014 10:13:48 -0000 Subject: [GHC] #9564: Floating point subnormals overrounded on output In-Reply-To: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> References: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> Message-ID: <057.6f11ad8736916b7458d670c9e95edbe2@haskell.org> #9564: Floating point subnormals overrounded on output -------------------------------------+------------------------------------- Reporter: jrp | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): Overrounding in the sense that I would expect something like 1.4013e-45 rather than 1.0e-45. I have not delved into the specs for Show Float / Double. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 8 13:53:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Sep 2014 13:53:47 -0000 Subject: [GHC] #9369: Data.List.unfoldr does not fuse and is not inlined. In-Reply-To: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> References: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> Message-ID: <060.8eea1a7f8f666da1680a06b8405428ae@haskell.org> #9369: Data.List.unfoldr does not fuse and is not inlined. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D198 | -------------------------------------+------------------------------------- Comment (by nomeata): Small followup: According to http://ghcspeed- nomeata.rhcloud.com/changes/?rev=78209d70596dcbfcb11ad1de1c961ab8479e531e&exe=2&env=nomeata%27s%20buildbot no significant changes in performance can be observed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 8 16:16:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Sep 2014 16:16:20 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.b758c69ff7525971bdb40e9171f3c08f@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 8 16:23:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Sep 2014 16:23:48 -0000 Subject: [GHC] #9369: Data.List.unfoldr does not fuse and is not inlined. In-Reply-To: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> References: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> Message-ID: <060.b8bf3c28dd144a5c2db3f7f19b85ec78@haskell.org> #9369: Data.List.unfoldr does not fuse and is not inlined. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D198 | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:9 nomeata]: > Small followup: According to http://ghcspeed- nomeata.rhcloud.com/changes/?rev=78209d70596dcbfcb11ad1de1c961ab8479e531e&exe=2&env=nomeata%27s%20buildbot no significant changes in performance can be observed. The reason for this is very simple: not a single one of those benchmarks uses `unfoldr` anywhere. The only benchmarks in the `nofib` tree that use it are the `fibon` ones, which are not run by default: {{{ [dfeuer at lemur nofib]$ find . -name "*hs" -exec grep unfoldr \{\} \; -print split n xs = unfoldr (g n) xs ./fibon/Hackage/Crypto/Codec/Text/Raw.hs blocks = map (fromOctets 256) (unfoldr h $ concat $ unfoldr g s) concat $ unfoldr g s where ./fibon/Hackage/Crypto/Codec/Encryption/Padding.hs import Data.List(unfoldr) unfoldr f $ md5s $ Str $ map (chr . fromIntegral) xs ./fibon/Hackage/Crypto/Data/Digest/MD5.hs unfoldr g unfoldr g ./fibon/Hackage/Crypto/Data/Digest/SHA1.hs padding x = unfoldr block $ paddingHelper x 0 (0::Int) (0::Integer) ./fibon/Hackage/Crypto/Data/Digest/SHA2.hs import Data.List (unfoldr) unroll = unfoldr step ./fibon/Hackage/Gf/src/runtime/haskell/Data/Binary.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 8 17:25:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Sep 2014 17:25:03 -0000 Subject: [GHC] #9495: Do What I Mean RULES for foldr2 look shady In-Reply-To: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> References: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> Message-ID: <060.3364b9461a458ad34303c394e6586ac2@haskell.org> #9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: highest => high * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 8 18:29:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Sep 2014 18:29:25 -0000 Subject: [GHC] #9558: "Illegal equational constraint" that might not be the users fault In-Reply-To: <047.9b1d3d881f2dea1952fccc5d58e63e62@haskell.org> References: <047.9b1d3d881f2dea1952fccc5d58e63e62@haskell.org> Message-ID: <062.9e8ab71e2a165a2c3ba66e697bd4cec1@haskell.org> #9558: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): could this just be an issue of precedence in the parser? (I don't have a current build of head right now so i cant try till later) ie TypeFam a (~) b vs (TypeFam a) ~ b ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 8 19:50:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Sep 2014 19:50:55 -0000 Subject: [GHC] #9565: T3500b exhaust simplifier ticks (loops?) on WAY=optasm Message-ID: <045.21253a4eab836dbd85b1b13d4815a773@haskell.org> #9565: T3500b exhaust simplifier ticks (loops?) on WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: T3500b | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ $ make fulltest TEST="T3500b" WAY=optasm =====> T3500b(optasm) 3767 of 4101 [0, 0, 0] cd ./typecheck/should_run && '/home/slyfox/dev/git/ghc- validate/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T3500b T3500b.hs -O -fasm >T3500b.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling Main ( T3500b.hs, T3500b.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20140907 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired foldr/augment To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 12441 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Attempt to increase '''-fsimpl-tick-factor''' does not help copiling sample. Looks like infinite inlining pass. The test source itself: {{{#!hs {-# LANGUAGE TypeFamilies, FlexibleContexts, UndecidableInstances #-} module Main where newtype Mu f = Mu (f (Mu f)) type family Id m type instance Id m = m instance Show (Id (f (Mu f))) => Show (Mu f) where show (Mu f) = show f showMu :: Mu (Either ()) -> String showMu = show item :: Mu (Either ()) item = Mu (Right (Mu (Left ()))) main = print (showMu item) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 8 19:53:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Sep 2014 19:53:34 -0000 Subject: [GHC] #9426: ghci triggers 'ASSERT failed! file compiler/ghci/Linker.lhs, line 906' In-Reply-To: <045.4a6b72a25dd245d66de01ff299d3a844@haskell.org> References: <045.4a6b72a25dd245d66de01ff299d3a844@haskell.org> Message-ID: <060.6841b3227b703c58be68d01a36193c51@haskell.org> #9426: ghci triggers 'ASSERT failed! file compiler/ghci/Linker.lhs, line 906' -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: ghci044 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by slyfox): * testcase: => ghci044 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 8 20:15:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Sep 2014 20:15:58 -0000 Subject: [GHC] #9566: T7891 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm Message-ID: <045.3cb2ff90fbfcc512737c7e9a31a0031c@haskell.org> #9566: T7891 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- ghc-HEAD: {{{ $ make fulltest TEST="T7891" WAY=optasm cd ./typecheck/should_compile && '/home/slyfox/dev/git/ghc- validate/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7891.hs -O -fasm -fno-warn-incomplete-patterns >T7891.comp.stderr 2>&1 Compile failed (status 256) errors were: *** Core Lint errors : in result of Simplifier *** : Warning: In the type ?a_12 -> t_aiF -> t_aiF? @ a_12 is out of scope *** Offending Program *** T7891.tf :: T7891.T [LclIdX, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] T7891.tf = GHC.Base.id `cast` (Sym T7891.NTCo:T[0] :: (forall t_ahj. t_ahj -> t_ahj) ~R# T7891.T) T7891.f :: forall t_ahw. t_ahw -> t_ahw [LclIdX, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] T7891.f = T7891.tf `cast` (T7891.NTCo:T[0] :: T7891.T ~R# (forall t_ahj. t_ahj -> t_ahj)) ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 8 20:16:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Sep 2014 20:16:23 -0000 Subject: [GHC] #9566: T7891 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm In-Reply-To: <045.3cb2ff90fbfcc512737c7e9a31a0031c@haskell.org> References: <045.3cb2ff90fbfcc512737c7e9a31a0031c@haskell.org> Message-ID: <060.f627d29d9f3876fb698153bbdbfc299d@haskell.org> #9566: T7891 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: T7891 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by slyfox): * testcase: => T7891 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 8 20:24:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Sep 2014 20:24:26 -0000 Subject: [GHC] #9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm Message-ID: <045.3ecedf0980b076ccd1110fcb386f8214@haskell.org> #9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: tc124 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- ghc-HEAD: {{{ $ make fulltest TEST="tc124" WAY=optasm =====> tc124(optasm) 3136 of 4101 [0, 0, 0] cd ./typecheck/should_compile && '/home/slyfox/dev/git/ghc- validate/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c tc124.hs -O -fasm -fno-warn-incomplete-patterns >tc124.comp.stderr 2>&1 Compile failed (status 256) errors were: *** Core Lint errors : in result of Simplifier *** : Warning: In the type ?a_12 -> a_aia -> a_aia? @ a_12 is out of scope *** Offending Program *** Foo.g :: Foo.T -> Foo.T [LclIdX, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20] 40 30}] Foo.g = \ (t_ahr :: Foo.T) -> case t_ahr of _ [Occ=Dead] { Foo.T ds_dlB ds_dlC -> Foo.T ds_dlB (\ (@ a_ai4) (@ b_ai5) _ [Occ=Dead] (y_aht :: b_ai5) -> y_aht) } ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 8 23:07:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Sep 2014 23:07:20 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.00a896634c4bffaac4a512e55f4b245d@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I've gone over practically the entire GHC source tree (I ran out of time before I could look at the last few validation tests files). === Good News === Very few files explicitly use `ExplicitForAll`. Of all the files that use `ExplicitForAll` or anything that implies it, only one, a file in the `fibon` benchmark suite, would need minor changes to work with `ScopedTypeVariables`. === Bad News === Lots and lots of files use extensions that imply `ExplicitForAll` and don't use `ScopedTypeVariables`. I don't personally see an obvious way to warn when something ''implying'' `ExplicitForAll` is used without `ScopedTypeVariables`, although someone else may be able to figure something out. === Question === Should we just bite the bullet and just make everything that currently implies `ExplicitForAll` imply `ScopedTypeVariables` instead? It seems, contrary to my earlier fears, that this is likely to break very little real code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 03:58:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 03:58:29 -0000 Subject: [GHC] #9568: Type classes that fully cover closed kinds Message-ID: <047.0403b5d3c61124bb9ff541418f195523@haskell.org> #9568: Type classes that fully cover closed kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: lowest | Milestone: ? Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When we have a closed kind (I think data kinds may be the only ones that are closed?), and a type class that takes only that kind as a parameter, and we have instances of the typeclass for every type in the kind, it would be nice if we didn't have to list it in the context of every function that uses it. Example: in `GHC.TypeLits`, this relationship exists between `Nat` and `KnownNat`, `Symbol` and `KnownSymbol`. It also arises in many of my uses of data kinds, because I often end up with a `KnownX` class that provides term-level things related to whatever the type is. The constraints tend to end up everywhere, which is noisy. As far as I can tell they don't really carry any information: a `KnownNat n` constraint where `n :: Nat` should be able to be discharged in the same way that something like `Show Bool` is, because regardless of which `n` we pick we know there will be an instance. (This is trickier for closed kinds like `Nat` and `Symbol` than for user- defined ones through the data kinds feature, because the former are inhabited by infinitely many types.) Perhaps we could have a pragma to inform the compiler that this situation exists for a certain typeclass, which the compiler could check in finite cases (like the ones arising for user-defined data kinds) by enumerating all the cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 04:56:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 04:56:09 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.eb8dfd59331f1feeef255dd052b12823@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dmcclean): * cc: dmcclean (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 05:02:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 05:02:14 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.b43beb0aa0675ae718e01bac00bf1b61@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by isaacdupree): Yes, bite the bullet! I'm one of the people who initially advocated for ExplicitForAll (https://www.mail-archive.com/haskell- prime at haskell.org/msg02765.html). + It sounds like the semantic inconsistency between "forall" with and without ScopedTypeVariables is annoying ? The downside is a hypothetical Haskell compiler that wanted to implement, say, RankNTypes but not ScopedTypeVariables would be stuck Seems to me that the plus is more important than the minus in today's Haskell world. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 07:21:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 07:21:44 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.b3cc8badd7ebedecede4a51992d1d650@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Specifically, apart from `-XScopedTypeVariables`, the following flags imply `-XExplicitForAll`: * `-XRankNTypes` * `-XLiberalTypeSynonyms` * `-XExistentialQuantification` So the concrete proposal is: * Abolish `-XExplicitForAll` * Make the above three flags imply `-XScopedTypeVariables`, which in turn would switch on the `forall` keyword, and make type variables have lexical scope. I would be fine with this. I'd like to hear more opinions. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 09:15:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 09:15:56 -0000 Subject: [GHC] #9494: Probable data corruption with GHCi 7.8.* and Zlib In-Reply-To: <047.c599b15a57b1de1c882b98999535443e@haskell.org> References: <047.c599b15a57b1de1c882b98999535443e@haskell.org> Message-ID: <062.ac6172a2dbf7c8b48f7c888a33b6785b@haskell.org> #9494: Probable data corruption with GHCi 7.8.* and Zlib -------------------------------------+------------------------------------- Reporter: nominolo | Owner: aseipp Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nominolo): Replying to [comment:3 rwbarton]: > The zlib library internally uses a bunch of unsafe functions (`unsafePerformIO`, `unsafeForeignPtrToPtr`) so this is also quite possibly just a bug in zlib. (See `Codec/Compression/Zlib/Stream.hsc`, it's quite scary.) Yes, it's possible. I looked through that module, but could find any use of the Really Scary `inlinePerformIO`. The scariest functions seem to be `push{Input,Output}Buffer`. Unless we know what really goes wrong, it's possible that other libraries have the same problem and may break in subtle ways on 7.8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 09:23:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 09:23:07 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.ad0be73f79f8f1392cbb3a16a23dda8e@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): I?m slightly worried that we?d breaking some code for little gain. I am accustomed to read type signatures as a local, self-contained thing, unless `ScopedTypeVariables` is on ? what?s wrong with keeping that behaviour? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 09:27:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 09:27:16 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.1d4fe3d69ffa5666bc0a0203346ed8ab@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): Note that, after some feedback, I've moved the document to the GHC Wiki: http://www.haskell.org/haskellwiki/Evaluation_order_and_state_tokens -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 10:52:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 10:52:10 -0000 Subject: [GHC] #9563: Support for deriving Generic1 for data families In-Reply-To: <047.5afce0493774ce2d5de4e9e316ca0dec@haskell.org> References: <047.5afce0493774ce2d5de4e9e316ca0dec@haskell.org> Message-ID: <062.a1e554e95c3b048605fd29fe0256992a@haskell.org> #9563: Support for deriving Generic1 for data families -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => dreixel * priority: normal => high * milestone: => 7.10.1 Comment: Pedro, might you look at this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 10:57:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 10:57:52 -0000 Subject: [GHC] #5395: Context reduction stack overflow without undecidable instances In-Reply-To: <044.cc587d7f60fab1552eaf50eae3520e7a@haskell.org> References: <044.cc587d7f60fab1552eaf50eae3520e7a@haskell.org> Message-ID: <059.c170a1fbcf1aeff7def2a66591dcb861@haskell.org> #5395: Context reduction stack overflow without undecidable instances -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 Resolution: | Keywords: type family, Operating System: | termination Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): We now have `-fcontext-stack=N` (for type classes) and `-ftype-function- depth=N` (for type functions). I suspect that when splitting the two we put the type-class one back to 20. I'll increase it to 100. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 11:00:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 11:00:43 -0000 Subject: [GHC] #9561: Clean up mergeSATInfo In-Reply-To: <045.e75f4cf175b68122b78f890c1d8597ac@haskell.org> References: <045.e75f4cf175b68122b78f890c1d8597ac@haskell.org> Message-ID: <060.3df90890ba69ebefc82c3634ee961a2e@haskell.org> #9561: Clean up mergeSATInfo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Let's do #9374 before implementing this patch. Right now SAT is only run when you say `-fstatic-argument-transformation` (ie almost never) so it would be hard to test this (doubtless excellent) refactoring thoroughly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 11:01:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 11:01:28 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.0cb99e7252f1c5cf1421b833016c7463@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): When fixing this ticket, do #9561 at the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 11:04:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 11:04:55 -0000 Subject: [GHC] #5395: Context reduction stack overflow without undecidable instances In-Reply-To: <044.cc587d7f60fab1552eaf50eae3520e7a@haskell.org> References: <044.cc587d7f60fab1552eaf50eae3520e7a@haskell.org> Message-ID: <059.7b77aba09944ee750f8d87ea437c3cd9@haskell.org> #5395: Context reduction stack overflow without undecidable instances -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 Resolution: | Keywords: type family, Operating System: | termination Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > I suspect that when splitting the two we put the type-class one back to 20. Correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 11:14:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 11:14:21 -0000 Subject: [GHC] #9558: "Illegal equational constraint" that might not be the users fault In-Reply-To: <047.9b1d3d881f2dea1952fccc5d58e63e62@haskell.org> References: <047.9b1d3d881f2dea1952fccc5d58e63e62@haskell.org> Message-ID: <062.1d381a83f68a696d17469b1d4041b975@haskell.org> #9558: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Reid is right. Is the change a good design choice? In general I think "yes". The language extensions are meant to say whether or not you are using a language extension in a module; and if you need an extension to write down the type of a function you are defining I think that yes, you are using the extension. But if it causes major backward-compatibility pain, that might have outweighed it (if we'd known). But now 7.8 is out. I'll close this as invalid (since it is by-design), but if anyone feels strongly we should actually change back (in 7.10) to the previous design (where GHC would infer a type that you could not write in a type signature without adding more flags), then please open a new ticket to say so and why. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 12:38:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 12:38:50 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.723e1ac70d964c1d3d14f79cfb148ed2@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): I'm inclined to agree with Nomeata. Or at least, A survey of how this would impact code that's currently buildable on hackage would be needed to accurately evaluate the scope of the impact. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 12:52:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 12:52:43 -0000 Subject: [GHC] #9479: Report required constraints when reporting the type of a hole In-Reply-To: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> References: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> Message-ID: <071.6f80e1f59ca863befa0b459ff1ec55c0@haskell.org> #9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: | Owner: dominiquedevriese | Status: new Type: feature | Milestone: request | Version: 7.8.3 Priority: low | Keywords: holes Component: Compiler | Architecture: Unknown/Multiple (Type checker) | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I think this would be fairly easy to implement, and I talked to someone at ICFP who plans to do so. Happy to offer guidance. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 13:05:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 13:05:25 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.3e1f0de2b15f9858be02dfdc4b50f27b@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): This only affects code that does something a bit strange. In particular, it has to use a `forall` in an outer position (not for a higher-rank type or an eqxistential) and it reuse the same type variable without a new `forall`. I'd be happy to participate in a survey of Hackage code, but I'm not sure how to go about that?there are thousands of files on Hackage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 13:17:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 13:17:39 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.2ea0fcc6feaa73d1271faed9ca178c00@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm -1 on this, along the same lines as nomeata. I think it would be unexpected to have, say, `ExistentialQuantification` imply `ScopedTypeVariables`. If there were a clear upside, I would back off, but I don't see a compelling reason to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 13:30:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 13:30:53 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.e9d3a63f1708c25844b3283399c9fe14@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > I'd be happy to participate in a survey of Hackage code, but I'm not sure how to go about that?there are thousands of files on Hackage. I?d recommend looking at stackage, which has a collection of packages that compile with each other, and ways to run it (haven?t done that myself yet, though). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 13:53:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 13:53:29 -0000 Subject: [GHC] #9561: Clean up mergeSATInfo In-Reply-To: <045.e75f4cf175b68122b78f890c1d8597ac@haskell.org> References: <045.e75f4cf175b68122b78f890c1d8597ac@haskell.org> Message-ID: <060.fb3d1c5e6392e493c1aa6ff70092da7e@haskell.org> #9561: Clean up mergeSATInfo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:2 simonpj]: > Let's do #9374 before implementing this patch. Right now SAT is only run when you say `-fstatic-argument-transformation` (ie almost never) so it would be hard to test this (doubtless excellent) refactoring thoroughly. > > Simon I understand your concern, but if you look at it, this is a ''very'' limited change. I think two pairs of eyeballs and the type checker passing it should be pretty convincing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 14:34:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 14:34:04 -0000 Subject: [GHC] #9568: Type classes that fully cover closed kinds In-Reply-To: <047.0403b5d3c61124bb9ff541418f195523@haskell.org> References: <047.0403b5d3c61124bb9ff541418f195523@haskell.org> Message-ID: <062.caac9a1779731be4a607663b737a1a34@haskell.org> #9568: Type classes that fully cover closed kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: new request | Milestone: ? Priority: lowest | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): This is a natural thing to want but, alas, it's not so simple. It's not enough for the compiler to know that some instance exists. It has to know which instance to use, because the choice of instance affects the runtime semantics of the program. From a theory point of view, polymorphism over closed kinds has the same parametricity properties as polymorphism over open kinds like `*`. If I have a function `f :: forall (b :: Bool). Proxy b -> String` then `f`'s behavior cannot depend on the choice of `b`, so `f (Proxy :: Proxy False)` must be equal to `f (Proxy :: Proxy True)`, just like a function `g :: Maybe a -> String` must satisfy `g (Nothing :: Maybe Int)` = `g (Nothing :: Maybe Bool)`. From an implementation point of view there is no difference at all at runtime between `Proxy :: Proxy False` and `Proxy :: Proxy True`, so simply for that reason it's impossible for any function to distinguish them. But with a class constraint `C b`, even when `C` has instances for both `False` and `True`, `f`'s behavior can depend on `b`, as I'm sure you know. This is possible because the `C b` constraint gets translated to an extra value-level argument to the function. So, `f :: forall (b :: Bool). C b => Proxy b -> String` is really different from `f :: forall (b :: Bool). Proxy b -> String` even when `C b` is satisfied for each individual type `b :: Bool`. In light of all this, I'm not sure what change along the lines of your suggestion would be possible. IIRC Richard Eisenberg's "dependent Haskell" project includes a non-parametric universal quantifier; perhaps that is related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 14:44:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 14:44:57 -0000 Subject: [GHC] #9568: Type classes that fully cover closed kinds In-Reply-To: <047.0403b5d3c61124bb9ff541418f195523@haskell.org> References: <047.0403b5d3c61124bb9ff541418f195523@haskell.org> Message-ID: <062.d9fe2c1ccabac605adfb409eee38a160@haskell.org> #9568: Type classes that fully cover closed kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: new request | Milestone: ? Priority: lowest | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree fully with Reid (rwbarton). Those "class constraints" are really, under the hood, implicit parameters (dictionaries) passed around at runtime. Given that they have runtime significance, I don't think it's a good idea to hide them from the programmer. On the relationship to Pi-types: As described in [https://www.youtube.com/watch?v=O805YjOsQjI this video] and [wiki:DependentHaskell this wiki page], I'm working on a version of GHC that allows a type parameter to be made available at runtime. This feature could be used to simulate dictionary passing (I believe), by examining the type parameter at runtime and making decisions based on it. So, I guess this might improve the syntax a bit -- hard to say for sure at this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 14:48:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 14:48:00 -0000 Subject: [GHC] #9568: Type classes that fully cover closed kinds In-Reply-To: <047.0403b5d3c61124bb9ff541418f195523@haskell.org> References: <047.0403b5d3c61124bb9ff541418f195523@haskell.org> Message-ID: <062.b9f6f9c82d4d271e1b294ebf9f911c3b@haskell.org> #9568: Type classes that fully cover closed kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: new request | Milestone: ? Priority: lowest | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dmcclean): Great point. Not sure what I was thinking, sorry. Regarding "If I have a function `f :: forall (b :: Bool). Proxy b -> String` then `f`'s behavior cannot depend on the choice of `b`", I think I got off track by thinking that the binding happens in two stages, and that when type type-level lambda was applied it could "pick" which term-level function it wanted to return after inspecting the type argument, and that all of that always happened at compile time. But it doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 14:48:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 14:48:24 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.d9723586577637d8bcc759ec97c066f5@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by isaacdupree): We could change ExplicitForAll to be a subset of ScopedTypeVariables. Make "forall" always introduce type variable scopes, but error if any type variable is actually used in a scoped way without ScopedTypeVariables. (I am not volunteering to implement that change - I don't feel strongly enough about this) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 15:13:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 15:13:47 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.6366e96ab58204832ef34675d31faf16@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Before embarking on the implementation, is everyone convinced that the proposed syntax {{{ type family F a :: * | result -> a }}} is the best one? I understand the desire to support injectivity in some parameters but not others. For ''closed'' type classes, can't we infer injectivity, rather than having to declare it? (Although I suppose that the ability to declare is always a Good Thing.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 15:20:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 15:20:37 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.3743d83c5cde9a84f795bb2e6ffe2336@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by cetu86): I have to confirm having exactly the same problem. build command line is {{{ ./configure --target=arm-unknown-linux-gnueabi --enable-unregisterised --with-nm=/usr/bin/nm --prefix=$HOME/haskell/ghc-build && make quick- cross }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 15:42:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 15:42:07 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.f4a0c5ae36d8b888fc7cac04b9751fa0@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): That syntax precludes the possibility of `result` being the name of an argument to the function. Using `Result` avoids this problem, but that would be a capitalized keyword, which is strange. The other possibility that avoids stealing the name `result` is to use the type family itself to represent the result: `type family F a | F -> a`, but that's a little strange. I guess I favor the last syntax the most. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 15:42:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 15:42:54 -0000 Subject: [GHC] #9569: Tuple constraints don't work right Message-ID: <046.31f45b75873be125a1cc8887558fe856@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider this program: {{{ {-# LANGUAGE RankNTypes, ConstraintKinds, KindSignatures, DataKinds, TypeFamilies #-} module Wrong where import GHC.Prim data Proxy (c :: Constraint) class Deferrable (c :: Constraint) where defer :: Proxy c -> (c => a) -> a deferPair :: (Deferrable c1, Deferrable c2) => Proxy (c1,c2) -> ((c1,c2) => a) -> a deferPair = undefined instance (Deferrable c1, Deferrable c2) => Deferrable (c1,c2) where -- defer p f = deferPair p f -- Succeeds defer = deferPair -- Fails }}} The first (commented-out) definition of `defer` in the instance declaration succeeds; but the second fails with an utterly bogus message {{{ ConstraintBug.hs:27:13: Could not deduce (c1 ~ (c1, c2)) from the context (Deferrable c1, Deferrable c2) }}} The reason is that when type-checking the method defintion we try to unify {{{ ((c1,c2) => a) ~ ((gamma1, gamma2) => alpha) }}} where * the LHS comes from instantiating the signature `(c => a)` (from the class decl) with `(c1,c2)/c` from the instance. * the RHS comes from instantiating the type of `deferPair` with fresh unification variables. The difficulty is that in the type of `deferPair`, the concrete syntax {{{ deferPair :: ...((c1,c2) => a)... }}} is really just syntactic sugar for {{{ deferPair :: ...(c1 => c2 => a)... }}} i.e. curried. But the function in the instantiated signature really has one constraint argument, a pair, not two. It's not clear how to fix this. It would actually be more consistent if {{{ f :: (Eq a, Show a) => blah }}} really did take a pair of dictionaries, rather than two curried dictionaries. But that would be a pretty big change, forced by a corner case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 15:45:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 15:45:45 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.696cf83aacfeeab629b0fb5c8ef14ec3@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): We could also reuse an existing keyword, e.g., `type family F a :: * | type -> a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 15:48:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 15:48:10 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.435bfe287df85294db70416a1d898a32@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by rwbarton): Try adding `--with-gcc=[whatever the path to the C cross-compiler is]` to the configure command line. I've found that I need to do this when cross- compiling. I think that configure detecting the C cross-compiler worked in 7.8.2 and broke in 7.8.3 but I'm not 100% sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 15:52:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 15:52:45 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.eae1cfacc055411734725afae9b51993@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): A conversation with Ulf Norell (the first implementor of Agda) led to this interesting thought: We may not want injectivity -- we may want a weaker property, which I'll term "head-injectivity". The equations defining a head-injective function all have RHSs with different heads. What appears below the heads does not matter. Here is an example: {{{#!hs type family F a where F (Just x) = True F Nothing = False }}} This function is ''not'' injective: `F (Just 1) ~ F (Just 2)`. Yet, it is head-injective. If the type-inferencer knows that `F x ~ True`, it can then refine `x ~ Just y` for some fresh unification variable `y`. This improvement may be enough to make further progress. Of course, injectivity does not imply head-injectivity. Consider {{{#!hs type family G a where G True = Just 1 G False = Just 2 }}} This function is injective but not head-injective. So, implementing only head-injectivity will miss this case. But, perhaps we can refine the notion of head-injectivity simply to mean that the RHSs don't unify. The reason I'm bringing this up is that head-injectivity is, as I understand it, implemented in Agda and used during type inference. It intrigues me to think that we can make progress in the case of `F`, a non- injective function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 15:54:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 15:54:54 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.88e57a3881f342eecd6a9205a0c4fe60@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): I think the bulk of the work with injectivity will be done under the hood. Changing the syntax later on will not be difficult and I don't want to be blocked by bikeshedding. Inferring injectivity for closed type families is something that indeed requires more discussion. But again, I feel I can make at least some progress without any binding decissions on this matter being made. I don't like any of Richard's proposals: - if we introduced `Result` this would be the first capitalized keyword (reserved word?) in Haskell. I don't like such inconsistency. Notice also that `result` might conflict with type variable names in type family head but that is a local conflict that restricts only the names possible to use for type variables. On the other hand `Result` might conflict with a name of a type (or type family), which is more of a global thing. - if we use syntax that uses type family name then we will get something like `type family F a b c | F b -> a c` and `F b` looks strange given that `F`'s arity is 3. It looks as if `F` could be partially applied. I don't think that restricting the use of `result` word in type family head is a big problem - we've already done that with `role`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 16:01:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 16:01:05 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.6d7a343a49bbee93cbcd2fbeb59b1c21@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Richard, I don't understand your terminology here (though I do understand the `F` example): > The equations defining a head-injective function all have RHSs with different heads. What appears below the heads does not matter. Could you explain what you mean by `RHSs with different heads` and `below the heads`? Up till now I thought that the term "head" refers to `type family F a` part of the declaration. I also don't understand why `G` is not head-injective, but perhaps this will become clear to me once earlier questions are answered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 16:11:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 16:11:54 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.ad4fec809addd718d313b90f7f7c3823@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:49 jstolarek]: > I don't think that restricting the use of `result` word in type family head is a big problem - we've already done that with `role`. The use of `role` doesn't steal syntax: it can be used only after the word `type` in a top-level declaration, where a capitalized identifier is expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 16:13:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 16:13:05 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.52f42caaa6440d275bbfa2e88302f58e@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:50 jstolarek]: > Could you explain what you mean by `RHSs with different heads` and `below the heads`? Up till now I thought that the term "head" refers to `type family F a` part of the declaration. Here, "head" means the head of the RHS type, not the type declaration -- it's the root of the type's AST. Does that help? > > I also don't understand why `G` is not head-injective, but perhaps this will become clear to me once earlier questions are answered. `G` isn't head-injective because both RHSs are headed by `Just`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 16:24:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 16:24:01 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.41eb18cbcd7ca6b99d0d990b47a5b8ab@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:52 goldfire]: > Here, "head" means the head of the RHS type, not the type declaration -- it's the root of the type's AST. Does that help? Yes, now I fully understand. Also, if I understood correctly it is possible to have both injectivity and head-injectivity in the compiler, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 16:26:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 16:26:32 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.372fb1aaeda2c304f343441d19db1dec@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:51 goldfire]: > Replying to [comment:49 jstolarek]: > > I don't think that restricting the use of `result` word in type family head is a big problem - we've already done that with `role`. > > The use of `role` doesn't steal syntax: it can be used only after the word `type` in a top-level declaration, where a capitalized identifier is expected. Oops, sorry for defamation then ;-) Still, I think that the price to pay for using `result` will not be that high. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 16:38:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 16:38:03 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.3177ca6d084f3181b0d1a15f04349882@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:53 jstolarek]: > Also, if I understood correctly it is possible to have both injectivity and head-injectivity in the compiler, right? Yes, but confusing, especially if there is syntax for both. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 16:42:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 16:42:31 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.29e672483a39ccdd8fc87ad3948bfed2@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by cetu86): Thanks for that quick answer. I did as you told me, also passing the argument {{{ --with-gcc=`which arm-unknown-linux-gnueabi-gcc` }}} to configure. Now it goes past the last error. But some way down the road this happens {{{ /bin/sh ./libtool --mode=compile /usr/bin/gcc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -DFFI_BUILDING -I. -I../include -Iinclude -I../src -DFFI_BUILDING -g -fno-stack-protector -w -MT src/arm/sysv.lo -MMD -MP -MF $depbase.Tpo -c -o src/arm/sysv.lo ../src/arm/sysv.S &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: /usr/bin/gcc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -DFFI_BUILDING -I. -I../include -Iinclude -I../src -DFFI_BUILDING -g -fno-stack-protector -w -MT src/arm/sysv.lo -MMD -MP -MF src/arm/.deps/sysv.Tpo -c ../src/arm/sysv.S -fPIC -DPIC -o src/arm/.libs/sysv.o ../src/arm/sysv.S: Assembler messages: ../src/arm/sysv.S:64: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:160: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:161: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:162: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:163: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:164: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:166: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:167: Error: unknown pseudo-op: `.arm' ../src/arm/sysv.S:167: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:168: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:169: Error: no such instruction: `stmfd sp!,{r0-r3,fp,lr}' ../src/arm/sysv.S:170: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:171: Error: too many memory references for `mov' ../src/arm/sysv.S:173: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:175: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:176: Error: too many memory references for `sub' ../src/arm/sysv.S:178: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:179: Error: too many memory references for `mov' ../src/arm/sysv.S:180: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:182: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:183: Error: no such instruction: `bl ffi_prep_args' ../src/arm/sysv.S:185: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:186: Error: no such instruction: `ldmia sp,{r0-r3}' ../src/arm/sysv.S:188: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:189: Error: too many memory references for `sub' ../src/arm/sysv.S:190: Error: no such instruction: `ldr ip,[fp]@load fn()in advance' ../src/arm/sysv.S:191: Error: expecting operand after ','; got nothing ../src/arm/sysv.S:192: Error: no such instruction: `movhs lr,' ../src/arm/sysv.S:193: Error: too many memory references for `add' ../src/arm/sysv.S:195: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:196: Error: too many memory references for `mov' ../src/arm/sysv.S:196: Error: too many memory references for `mov' ../src/arm/sysv.S:198: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:199: Error: too many memory references for `mov' ../src/arm/sysv.S:201: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:202: Error: no such instruction: `ldr r2,[sp,' ../src/arm/sysv.S:204: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:205: Error: no such instruction: `ldr r3,[sp,' ../src/arm/sysv.S:207: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:208: Error: expecting operand after ','; got nothing ../src/arm/sysv.S:209: Error: no such instruction: `beq .Lepilogue' ../src/arm/sysv.S:211: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:212: Error: expecting operand after ','; got nothing ../src/arm/sysv.S:216: Error: no such instruction: `streq r0,[r2]' ../src/arm/sysv.S:217: Error: no such instruction: `beq .Lepilogue' ../src/arm/sysv.S:219: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:220: Error: expecting operand after ','; got nothing ../src/arm/sysv.S:224: Error: no such instruction: `stmeqia r2,{r0,r1}' ../src/arm/sysv.S:227: Error: no such instruction: `beq .Lepilogue' ../src/arm/sysv.S:229: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:230: Error: expecting operand after ','; got nothing ../src/arm/sysv.S:231: Error: no such instruction: `stfeqs f0,[r2]' ../src/arm/sysv.S:232: Error: no such instruction: `beq .Lepilogue' ../src/arm/sysv.S:234: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:235: Error: expecting operand after ','; got nothing ../src/arm/sysv.S:236: Error: no such instruction: `stfeqd f0,[r2]' ../src/arm/sysv.S:244: Error: no such instruction: `ldmia sp!,{r0-r3,fp,pc}' ../src/arm/sysv.S:248: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:269: Error: unknown pseudo-op: `.arm' ../src/arm/sysv.S:269: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:270: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:271: Error: too many memory references for `add' ../src/arm/sysv.S:272: Error: no such instruction: `stmfd sp!,{ip,lr}' ../src/arm/sysv.S:273: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:274: Error: too many memory references for `add' ../src/arm/sysv.S:275: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:276: Error: too many memory references for `sub' ../src/arm/sysv.S:277: Error: invalid char '[' beginning operand 2 `[sp' ../src/arm/sysv.S:278: Error: too many memory references for `add' ../src/arm/sysv.S:279: Error: no such instruction: `bl ffi_closure_SYSV_inner' ../src/arm/sysv.S:280: Error: expecting operand after ','; got nothing ../src/arm/sysv.S:281: Error: no such instruction: `beq .Lretint' ../src/arm/sysv.S:283: Error: expecting operand after ','; got nothing ../src/arm/sysv.S:287: Error: no such instruction: `beq .Lretfloat' ../src/arm/sysv.S:290: Error: expecting operand after ','; got nothing ../src/arm/sysv.S:294: Error: no such instruction: `beq .Lretdouble' ../src/arm/sysv.S:297: Error: expecting operand after ','; got nothing ../src/arm/sysv.S:301: Error: no such instruction: `beq .Lretlongdouble' ../src/arm/sysv.S:304: Error: expecting operand after ','; got nothing ../src/arm/sysv.S:305: Error: no such instruction: `beq .Lretlonglong' ../src/arm/sysv.S:307: Error: too many memory references for `add' ../src/arm/sysv.S:308: Error: no such instruction: `ldmfd sp,{sp,pc}' ../src/arm/sysv.S:310: Error: no such instruction: `ldr r0,[sp]' ../src/arm/sysv.S:311: Error: no such instruction: `b .Lclosure_epilogue' ../src/arm/sysv.S:313: Error: no such instruction: `ldr r0,[sp]' ../src/arm/sysv.S:314: Error: no such instruction: `ldr r1,[sp,' ../src/arm/sysv.S:315: Error: no such instruction: `b .Lclosure_epilogue' ../src/arm/sysv.S:319: Error: no such instruction: `ldfs f0,[sp]' ../src/arm/sysv.S:320: Error: no such instruction: `b .Lclosure_epilogue' ../src/arm/sysv.S:322: Error: no such instruction: `ldfd f0,[sp]' ../src/arm/sysv.S:323: Error: no such instruction: `b .Lclosure_epilogue' ../src/arm/sysv.S:325: Error: no such instruction: `ldfd f0,[sp]' ../src/arm/sysv.S:326: Error: no such instruction: `b .Lclosure_epilogue' ../src/arm/sysv.S:330: Error: junk at end of line, first unrecognized character is `@' ../src/arm/sysv.S:499: Error: no such instruction: `stmfd sp!,{r0-r3}' ../src/arm/sysv.S:500: Error: no such instruction: `ldr r0,[pc]' ../src/arm/sysv.S:501: Error: no such instruction: `ldr pc,[pc]' make[5]: *** [src/arm/sysv.lo] Error 1 make[5]: Leaving directory `/mnt/hd/extra/haskell/ghc/libffi/build/arm- unknown-linux-gnueabi' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/mnt/hd/extra/haskell/ghc/libffi/build/arm- unknown-linux-gnueabi' make[3]: *** [all] Error 2 make[3]: Leaving directory `/mnt/hd/extra/haskell/ghc/libffi/build/arm- unknown-linux-gnueabi' make[2]: *** [all-all] Error 2 make[1]: *** [libffi/stamp.ffi.static-shared.build] Error 2 make: *** [quick-cross] Error 2 }}} Looks like its trying to compile arm-stuff using my normal gcc, not the cross-gcc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 17:17:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 17:17:54 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.02d31f9d211b5d9dff74cf0371beddaf@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by rwbarton): Hmm, so that's in libffi. Check how it was configured (`libffi/build/arm- unknown-linux-gnueabi/config.log` should tell you) and see whether anything looks amiss there. Perhaps you needed to clean more before re- configuring (`make distclean` should probably be enough, but `make maintainer-clean` is the ultimate hammer). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 17:37:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 17:37:23 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.b85483e72c65f698b289e2eb0155563d@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): whats missing is a good motivation for why we need do this breaking change. (ie whats the merits and demerits) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 18:42:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 18:42:16 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.be422ed6e58e9688ab0338f31a687f71@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): This issue (if it's an issue) isn't with SAT, but may affect it: Sometimes `Rec` groups include things they don't (seem to) need to, so the the current SAT will see "mutual recursion" when there's only self recursion, and SAT won't be applied. Should I open a separate ticket to investigate/fix this, or is it desirable for some reason? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 18:48:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 18:48:22 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.bc38e37f5a13eb71d3eb786b3995fa1e@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by cetu86): I did the maintainer-clean, then a {{{ perl boot }}} and then again {{{ ./configure --target=arm-unknown-linux-gnueabi --enable-unregisterised --with-gcc=`which arm-unknown-linux-gnueabi-gcc` --with-nm=/usr/bin/nm --prefix=/home/daniel/haskell/ghc-build && make quick-cross }}} Now I get {{{ mv libraries/integer-gmp/gmp/gmpbuild/ltmain.sh libraries/integer- gmp/gmp/gmpbuild/ltmain.sh.orig sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < libraries/integer- gmp/gmp/gmpbuild/ltmain.sh.orig > libraries/integer- gmp/gmp/gmpbuild/ltmain.sh cd libraries/integer-gmp/gmp; (set -o igncr 2>/dev/null) && set -o igncr; export SHELLOPTS; \ PATH=`pwd`:$PATH; \ export PATH; \ cd gmpbuild && \ CC=/home/daniel/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown- linux-gnueabi-gcc NM=/usr/bin/nm AR=/home/daniel/x-tools/arm-unknown- linux-gnueabi/bin/arm-unknown-linux-gnueabi-ar /bin/sh ./configure \ --enable-shared=no \ --host=x86_64-unknown-linux --build=x86_64-unknown-linux checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking ABI=64 checking whether /home/daniel/x-tools/arm-unknown-linux-gnueabi/bin/arm- unknown-linux-gnueabi-gcc is gcc... yes checking compiler /home/daniel/x-tools/arm-unknown-linux-gnueabi/bin/arm- unknown-linux-gnueabi-gcc -O2 -pedantic -m64 ... no checking ABI=32 checking whether /home/daniel/x-tools/arm-unknown-linux-gnueabi/bin/arm- unknown-linux-gnueabi-gcc is gcc... yes checking compiler /home/daniel/x-tools/arm-unknown-linux-gnueabi/bin/arm- unknown-linux-gnueabi-gcc -m32 -O2 -pedantic -fomit-frame-pointer ... no checking compiler /home/daniel/x-tools/arm-unknown-linux-gnueabi/bin/arm- unknown-linux-gnueabi-gcc -O2 -pedantic -fomit-frame-pointer ... no, program does not run configure: error: could not find a working compiler, see config.log for details make[1]: *** [libraries/integer-gmp/gmp/gmp.h] Error 1 make: *** [quick-cross] Error 2 }}} Again, it's seems like it's trying to compile gmp with an arm compiler for x64, or am I wrong? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 21:18:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 21:18:05 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.ffd9998e0b347a6f42c12150ac104f10@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by rwbarton): libgmp should be being configured with `--host=arm-unknown-linux-gnueabi`. I think this is a bug in the build system and currently you probably just want to use integer-simple instead. I don't think `make quick-cross` actually does anything... you should set up a `build.mk` (copied from `build.mk.sample`) and add `INTEGER_LIBRARY = integer-simple`. I think pretty much any `BuildFlavour` should work but note that the `quick-cross` and `perf-cross` flavours only build a ''cross-compiler'' and not a ''cross-compiled compiler'' that runs on the target. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 21:21:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 21:21:22 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.fff3f0f74444a941ed3de518312ab57e@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by MikolajKonarski): I get the original problem (the need to manually insert --ld- option="-melf_i386") already when using a 32bit GHC on 64bit Linux (no proper cross-compilation): https://ghc.haskell.org/trac/ghc/ticket/9421#comment:2 It would be helpful if that and other parameters where inserted automatically based on HOST/BUILD/TARGET. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 21:23:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 21:23:38 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.ea0502ab0a9958513000ab7b9305f1c4@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: 6086 GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * blockedby: => 6086 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 22:08:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 22:08:37 -0000 Subject: [GHC] #9494: Probable data corruption with GHCi 7.8.* and Zlib In-Reply-To: <047.c599b15a57b1de1c882b98999535443e@haskell.org> References: <047.c599b15a57b1de1c882b98999535443e@haskell.org> Message-ID: <062.4dc09799bd07a31962bb179502413654@haskell.org> #9494: Probable data corruption with GHCi 7.8.* and Zlib -------------------------------------+------------------------------------- Reporter: nominolo | Owner: aseipp Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well the error from zlib is not that scary either: it just means that the zlib API is being used incorrectly. Given that - there is no strong evidence of a compiler bug here - the zlib source is largely incomprehensible I suggest you submit a bug report to the zlib package also. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 22:20:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 22:20:14 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.c6718dd9f37e6303d763aeaaf692b173@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I can't tell without a concrete example. Can you offer one? Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 23:27:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 23:27:13 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.4da73af5b6bfb5cd73ce2f638b8fee83@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9421 | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by cetu86): Thanks again, for the reply. :-) Don't know why I thought passing "quick-perf" as an argument to make would choose the flavor. I now did as you said, created a build.mk from build.mk.sample and set {{{ BuildFlavour = quick-cross }}} which pulls in {{{ INTEGER_LIBRARY = integer-simple }}} I only need the simple cross-compiler (at the moment). Now I come as far as {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -package-name ghc-7.8.3 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP- DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.1 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package hoopl-3.10.0.1 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.10.0.0 -package time-1.4.2 -package transformers-0.3.0.0 -package unix-2.7.0.2 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -DNO_REGS -DNOSMP -optc-DNOSMP -optc- DTHREADED_RTS -DSTAGE=2 -O0 -fllvm -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -c compiler/hsSyn/Convert.lhs -o compiler/stage2/build/Convert.o compiler/hsSyn/Convert.lhs:895:10: Not in scope: data constructor ?TH.ClassP? Perhaps you meant one of these: ?TH.ClassD? (imported from Language.Haskell.TH.Syntax), ?TH.ClassD? (imported from Language.Haskell.TH), ?TH.ClassI? (imported from Language.Haskell.TH.Syntax) compiler/hsSyn/Convert.lhs:900:10: Not in scope: data constructor ?TH.EqualP? make[1]: *** [compiler/stage2/build/Convert.o] Error 1 make: *** [all] Error 2 }}} TH stands for template haskell, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 9 23:34:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Sep 2014 23:34:30 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.b14c30f1a97e5f42505fc50aa01cb20d@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9421 | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by rwbarton): It does. Probably you have gotten your non-submodule subrepositories into an inconsistent state, something which is easy to do when checking out 7.8. The reliable way to check out 7.8 correctly is to start with a fresh clone: {{{ git clone -b ghc-7.8 git://git.haskell.org/ghc.git cd ghc ./sync-all get -b ghc-7.8 }}} Sorry the wiki can be unclear in places... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 00:29:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 00:29:34 -0000 Subject: [GHC] #9570: cryptarithm1 (normal) has bimodal runtime Message-ID: <045.fa946bac826030c2120da577fec65526@haskell.org> #9570: cryptarithm1 (normal) has bimodal runtime -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.9 suite | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I was investigating performance numbers for cryptarithm1 in #8199, I noticed that the numbers for this benchmark were curiously bimodal. Here are two representative samples from both sides of the distribution. {{{ ../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc-timing ; ../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc- timing ; ../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc-timing ; ../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc-timing ; ../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc- timing ; real 0m0.676s user 0m0.660s sys 0m0.013s <> real 0m0.610s user 0m0.603s sys 0m0.007s <> }}} I don't have any further resolution on the problem yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 00:38:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 00:38:18 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.b4496422c1ac00c7b2aabd8dfc4d2dfb@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:48 goldfire]: > A conversation with Ulf Norell (the first implementor of Agda) led to this interesting thought: We may not want injectivity -- we may want a weaker property, which I'll term "head-injectivity". > So when our goal is to make progress from the target expression towards the source expression, what hinders us to follow Omega and use narrowing to obtain the head? Tim Sheard has a nice 2006 paper on how to do it. It is really powerful and we could insist that exactly one solution exists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 01:30:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 01:30:43 -0000 Subject: [GHC] #9571: nofib should use criterion-style bootstrapping/sampling Message-ID: <045.5455eab068db49e1d11638c2709a378d@haskell.org> #9571: nofib should use criterion-style bootstrapping/sampling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.9 suite | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As I discovered when investigating situations like #9570, in some cases, test-cases in nofib are giving nonsense, and it's hard to tell unless you run nofib several times and notice that percentage differences are fluctuating up and down. The quality of the numbers we get for uninformed users would be better if we ran some statistical analysis to tell how many times to run the benchmark, and if there were lots of outliers (rather than just blindly summarizing all the runs using an average.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 01:51:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 01:51:57 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.9a9dddf6dc51e0214c7bec7087c18111@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9421 | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by cetu86): This did it. Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 02:36:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 02:36:42 -0000 Subject: [GHC] #9571: nofib should use criterion-style bootstrapping/sampling In-Reply-To: <045.5455eab068db49e1d11638c2709a378d@haskell.org> References: <045.5455eab068db49e1d11638c2709a378d@haskell.org> Message-ID: <060.197e392552e84a3fe6fa9ef07a1dac57@haskell.org> #9571: nofib should use criterion-style bootstrapping/sampling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: NoFib | Keywords: benchmark suite | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 5793 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * blocking: => 5793 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 09:26:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 09:26:40 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.0788a5194ffa96fcf8900efa6f8d7f67@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): (GHC does, in effect, use narrowing, I believe.) Let's stand back a bit. What are we trying to achieve. Here is the Number 1 Goal: if the type inference engine is trying to prove `F a ~ F beta`, where `a` is a skolem constant and `beta` is a unification variable, is it justified in fixing `beta := a`? If `F` is not injective the answer is "no". If it's injective, the answer is "yes". We have multiple examples of the need for this. More generally, our goal is to use injectivity to guide the decision about what type a unification varaible stands for. Injectivity also allows other such opportunities, beyond the Number 1 Goal above. Suppose `F` is injective, and we have {{{ F Int = True }}} Then if we have `F beta ~ True` we can deduce `beta := Int`. Richard raises further possiblities: possibly-partial information about the result might allow us to deduce possibly-partial information about the arguments. That is the stuff about head-injectivity and it seems to be potentially very complicated. Take a closed type family. If I tell you something (but perhaps not everything) about the result, perhaps you can tell me something (but perhaps not everything) about the argument. I don't know how clever you might be here, or how to declare the cleverness in an "injectivity signature" for open families. But we have no actual use-caes for anything except Number 1 Goal, for equalities of form `F t1 ~ F t2`. It seems that equalities of form `F t1 ~ some-type` offer potential opportunities, but I don't see a sweet spot. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 11:29:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 11:29:41 -0000 Subject: [GHC] #9572: nofib target for just building should be part of validate Message-ID: <045.5fcdc416d003e87a697cbb6b21514f65@haskell.org> #9572: nofib target for just building should be part of validate -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.8.2 suite | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- nofib is never run during validates, which makes it easy to bitrot (c.f. AMP changes). It would be better if: 1. We had a build target for just building nofib tests, not running them, (maybe optionally with optimizations turned off, or just `-fno-code`) and 2. This build target was executed during validates This should strike a balance between wanting to avoid having to spend a lot of time running the benchmarks on validate, while still exercising the nofib tests to some degree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 12:16:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 12:16:41 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.baeafcdd4cda277f345fe6a529c16201@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:56 heisenbug]: > Tim Sheard has a nice 2006 paper on how to do it. What's the title of this paper? I tried to google it but failed. Replying to [comment:45 simonpj]: > For closed type classes, can't we infer injectivity, rather than having to declare it? I thought about it and I believe this should be possible. But we could only infer normal injectivity. I believe an algorithm for inferring injectivity in some of the parameters (ie. things like `result a -> b c` or `result -> b c` for a 3-arity type family) would be exponential in the number of arguments. Inferring normal injectivity should be O(n^2^) at most, where n is the number of equations. Replying to [comment:57 simonpj]: > But we have no actual use-caes for anything except Number 1 Goal, for equalities of form `F t1 ~ F t2`. It looks like Conal Elliot has a use case for injectivity in only some arguments: http://www.haskell.org/pipermail/glasgow-haskell- users/2011-February/020027.html I'll contact him for more details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 14:41:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 14:41:11 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.0634a7fab5d5df199c2579defd83df32@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Simon's (very straightforward) example clarifies this in my mind -- I agree about just heading for plain old injectivity for open type families. If/when we want more involved reasoning for closed type families, where inference is possible, we can address that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 14:51:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 14:51:31 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.1ad56ebf8cadd5dccbac707c407f3243@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:58 jstolarek]: > Replying to [comment:56 heisenbug]: > > Tim Sheard has a nice 2006 paper on how to do it. > > What's the title of this paper? I tried to google it but failed. > "Type-level Computation Using Narrowing in ?mega", Elsevier, 2007 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 15:14:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 15:14:13 -0000 Subject: [GHC] #9564: Floating point subnormals overrounded on output In-Reply-To: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> References: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> Message-ID: <057.8fe4948eed935b3f92e45c50c6da48fb@haskell.org> #9564: Floating point subnormals overrounded on output -------------------------------------+------------------------------------- Reporter: jrp | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): the standard defines the read/show for Float/Double as {{{ instance Show Float where showsPrec p = showFloat instance Read Float where readsPrec p = readSigned readFloat instance Show Double where showsPrec p = showFloat instance Read Double where readsPrec p = readSigned readFloat }}} at the bottom of https://www.haskell.org/onlinereport/haskell2010/haskellch9.html#x16-1710009 then per https://www.haskell.org/onlinereport/haskell2010/haskellch38.html#x46-31400038 {{{ showFloat :: RealFloat a => a -> ShowS Show a signed RealFloat value to full precision using standard decimal notation for arguments whose absolute value lies between 0.1 and 9,999,999, and scientific notation otherwise. }}} then looking at the stuff in 4.7.0.1 base http://hackage.haskell.org/package/base-4.7.0.1/docs/src/GHC- Float.html#showFloat {{{ -- | Show a signed 'RealFloat' value to full precision -- using standard decimal notation for arguments whose absolute value lies -- between @0.1@ and @9,999,999@, and scientific notation otherwise. showFloat :: (RealFloat a) => a -> ShowS showFloat x = showString (formatRealFloat FFGeneric Nothing x) }}} I'll try to dig into this a teeny bit more, but I think thank as long as `(read . show) :: Float -> Float` acts as the identity function on all floating point values when we roundtrip them. (and as long as they get correctly parsed to that same internal value when read/showed between haskell and another language) phrased differently, if we dont have roughly that `read_hs . show_clang == read_clang . show_hs == read_clang . show_clang == read_hs . show_hs == id ` then yes we have a problem, but we dont quite show that problem with theses tests as above, right? We just demonstrate that the particular choice in default representation for show differs from C, right? Its important to remember that parsing a floating point number itself will do rounding to the nearest floating point value too. i'm trying to focus on some work work this week, but if someone could test that these roundtripining identities work out ok, that'd be awesome (I may try to do it soon myself, but who knows how long that will take to happen) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 15:25:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 15:25:51 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.f2d388a5c89d3fae0b69dec75811319a@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:59 goldfire]: > plain old injectivity for open type families. > more involved reasoning for closed type families, where inference is possible I'm not sure what design choices are hidden by these two statements. Do you mean that for open type families we would have: a) simple injectivity in the result only (via annotations) or b) injectivity in some of the arguments (also via annotations); whereas for closed type families we would admit the same kind of injectivity declarations as for open type families and perhaps also injectivity inference as proposed by me in comment 58? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 15:33:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 15:33:30 -0000 Subject: [GHC] #9573: Add warning for invalid digits in integer literals Message-ID: <045.6745c955d16114a85008c81a7aea2c4a@haskell.org> #9573: Add warning for invalid digits in integer literals -------------------------------------+------------------------------------- Reporter: vlopez | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Parser) | Version: 7.9 Keywords: parsing, integer, | Operating System: octal, binary, hexadecimal, | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Difficult (2-5 | None/Unknown days) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- In its latest version, GHC can parse binary (with `-XBinaryLiterals`), octal and hexadecimal literals: {{{#!hs > 0b101010 > 0o52 > 0x2A }}} Currently, the parser/lexer reads digits from the input as long as they are valid for the specified radix. All subsequent digits are interpreted as a new, separate token. If the user uses a digit which isn't valid for the radix, it may be reported with a non-obvious error message, or interpreted in surprising ways: {{{#!hs > :t 0o567 0o576 :: Num a => a > :t 0o5678 0o5678 :: (Num (a -> t), Num a) => t Prelude> :t 0x1bfah :1:7: Not in scope: ?h? > replicate 0o5678 [8,8,8,8,8,8,8... }}} We suggest warning the user when a literal of this sort is written, while respecting any other error messages and the original behaviour. More specifically, the parser or lexer would give a warning if a token starting with an alphanumeric character is found immediately after a numeric literal, without a blank between them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 15:33:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 15:33:43 -0000 Subject: [GHC] #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB In-Reply-To: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> References: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> Message-ID: <057.d1336774a71b759e1f5bdcf170c84bb9@haskell.org> #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: IEEE754 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): still haven't worked through this fully, BUT min/max for float/double in ghc haskell are certainly defined differently from the the 2008 IEEE floating point standard (nb: the definition of min/max in the ieee standard was only added to the 2008 version and merely codified certain unusual idioms/patterns from the C language useage of min/max on Nans). In contrast, GHC Haskell's compare is defined wrt a quiet (not signalling) comparison on input arguments (which mean that when min max have a nan in either arg, we just take the second arg currently.). Of course, this is a bit unsatisfactory if only because it makes min/max not commutative operations in the presence of NaN. (though in some respects I view the current IEEE definition that just codifies the C version as more problematical still!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 16:51:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 16:51:19 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.e76428fd8e712459ba9df690f427410b@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9421 | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by jpmasseria): @cetu86 Which toolchain are you using? I'm following these (https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi) instructions and the target that I'm going to try is arm-linux-gnueabihf and my with-gcc is `which arm-linux-gnueabihf-gcc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 17:03:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 17:03:07 -0000 Subject: [GHC] #9564: Floating point subnormals overrounded on output In-Reply-To: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> References: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> Message-ID: <057.b0b653073df62e3f16de85cd0c79a0a7@haskell.org> #9564: Floating point subnormals overrounded on output -------------------------------------+------------------------------------- Reporter: jrp | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): Are we not at risk of overcomplicating this? raskell (hugs, I think) shows {{{ 2**(-149) 1.40129846432483e-45 2**(-149)::Float 1.401298e-45 }}} which is more what I would expect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 17:37:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 17:37:38 -0000 Subject: [GHC] #9564: Floating point subnormals overrounded on output In-Reply-To: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> References: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> Message-ID: <057.4b9b18b30afb8367c650768ce93a16af@haskell.org> #9564: Floating point subnormals overrounded on output -------------------------------------+------------------------------------- Reporter: jrp | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): These extra digits past the decimal point suggest a degree of precision that doesn't exist in a Float: for instance 1.4013e-45 is the same Float as 1.4014e-45. In fact all the numbers 1.0e-45 through 2.0e-45 (and a bit farther in each direction) round to the same Float, so why not output the simplest one, 1.0e-45? This is the same logic by which we display the Float 1/10 as 0.1 and not, say, 0.10000000149 even though the latter is closer to the true value. printf's %g is not a format you can round-trip through: by default it always prints 6 digits (in this case the last digit would be 0 and is dropped). So it's not a good analogue of `show`. (Also, %g is printing a double, not a float, but it has the same behavior with 2^-1074^, the smallest positive double.) Python has similar behavior to GHC: it doesn't have single-precision floating point AFAIK, but for doubles, it displays 2^-1074^ as 5e-324, just like GHC displays 5.0e-324. Arguably we could drop the ".0" part, but I don't think that's worth changing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 18:12:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 18:12:05 -0000 Subject: [GHC] #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB In-Reply-To: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> References: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> Message-ID: <057.5d7cc7871e989656268283cac48a5441@haskell.org> #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: IEEE754 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): There is clearly no answer that is right for all uses: either the QNaN poisons the result (which is what you might expect, as it does so in all other arithmetic operations) or it doesn't (as in the IEE754r version). What seems to me to be clearly wrong is for the answer to depend on the order in which the arguments are presented. The underlying problem is that we are assuming that floating point numbers are orderable but they aren't when NaNs are included, so a definition of min / max in terms of the order relation is invalid. I think that the only answer is to have two separate min / max specialisations for floating point numbers and let the user decide which they need for their application. Whether one of these is the default or they are two newly named functions is a pragmatic decision that depends on how much existing code would be broken, although I cannot imagine that there would be much code that relied on the order of the arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 18:12:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 18:12:45 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.757a5af8a0e88ef63e4010a50b337ef7@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9421 | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by jpmasseria): @cetu86 following your instructions I get: {{{ johnma at aspire-ubuntu:~/ghc$ make -j2 ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/package-data.mk: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist-boot/package- data.mk: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist-boot /package-data.mk: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/package-data.mk: No such file or directory libraries/transformers/ghc.mk:3: libraries/transformers/dist-boot/package- data.mk: No such file or directory libraries/terminfo/ghc.mk:3: libraries/terminfo/dist-boot/package-data.mk: No such file or directory libraries/dph/ghc.mk:134: *** dph_th_deps(v): libraries/dph/dph-base_dist- install_GHCI_LIB not defined!. Stop. make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 18:27:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 18:27:26 -0000 Subject: [GHC] #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB In-Reply-To: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> References: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> Message-ID: <057.b0243cc107394a6e018efb7d5e24c2f4@haskell.org> #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: IEEE754 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): 1. IEEE 2008 defines a total order 2. yes we can provide different min/max for floating things, BUT those arent the min/max that come with Ord, its trivial to define a floating only version min or max that has the alternative behaviors, whats less trivial is fixing the specified semantics of the haskell side. I've spoken with the various folks who would actually need to vote on a proposal via the libraries list, and because theres no canonicity of any of the choices, there'll be enough disagreement that the status quo will stay as is. I'd love to get the nan poisoning variant to be the new default, but we'd need a good canonicity story for making that so. if we just did minPoison and minMissing, no one will use them (who wouldn't be rolling their own anyways), and we'd have to newtype float/double to give alt min/max ord definitions. its a mess, and we need a clear canonicity argument to change up the behavior though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 18:38:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 18:38:02 -0000 Subject: [GHC] #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB In-Reply-To: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> References: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> Message-ID: <057.b1f0d7a6cfeb5ea7937a408bf598d79c@haskell.org> #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: IEEE754 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): I think the simplest answer would be to change how we define compare to use the IEEE total order it'd still be *weird* on NANs, but it'd be commutative again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 18:50:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 18:50:04 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.7ab3b99f49cbba73980d81afc81e70b8@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9421 | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: Replying to [comment:17 cetu86]: > This did it. Thank you! Glad it's working. I took the opportunity to clean up Building/GettingTheSources a bit and investigate why `-with-gcc` is needed (https://phabricator.haskell.org/D204). Replying to [comment:19 jpmasseria]: {{{ libraries/dph/ghc.mk:134: *** dph_th_deps(v): libraries/dph/dph-base_dist- install_GHCI_LIB not defined!. Stop. }}} I encountered this error too when messing around with this stuff. I didn't really investigate what caused it, it seemed to be due to configure detecting the wrong C compiler possibly. I "resolved" it by removing `libraries/dph` since it isn't needed anyways and slows down the build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 19:04:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 19:04:55 -0000 Subject: [GHC] #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB In-Reply-To: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> References: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> Message-ID: <057.174947172b105a2373099ef0e0ad2e0b@haskell.org> #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: IEEE754 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): I, for one, would be happy with that solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 19:16:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 19:16:32 -0000 Subject: [GHC] #9564: Floating point subnormals overrounded on output In-Reply-To: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> References: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> Message-ID: <057.65ea51824a1c1a5d0026297321697c36@haskell.org> #9564: Floating point subnormals overrounded on output -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: simonmar => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 19:41:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 19:41:28 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.b87abead237bb597b3b6c5d6a39464e6@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9421 | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by cetu86): @jpmasseria: I edited comment 17 to add the "--no-dph" switch to sync-all. I actually did it that way, just forgot to post the right instructions here, sorry! I didn't use the official raspbian-toolchain, because I'm running archlinux on the pi and many libraries have different versions there. So I build a toolchain using crosstool-ng following these instructions http://www.kitware.com/blog/home/post/426. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 20:03:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 20:03:24 -0000 Subject: [GHC] #4290: hClose002 test fails on Solaris/x86 due to bad expected output In-Reply-To: <046.f33011e5dee0b08536c12b8f9def3d93@haskell.org> References: <046.f33011e5dee0b08536c12b8f9def3d93@haskell.org> Message-ID: <061.e388fc295e538479d698b86efe6fe249@haskell.org> #4290: hClose002 test fails on Solaris/x86 due to bad expected output -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.9 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: | Difficulty: Easy (less than 1 None/Unknown | hour) Test Case: hClose002 | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by oddsignals): * status: closed => new * testcase: => hClose002 * difficulty: => Easy (less than 1 hour) * version: 6.13 => 7.9 * architecture: x86 => x86_64 (amd64) * owner: igloo => * resolution: fixed => Comment: This fails identically on solaris-x64 and a similar stdout should be added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 23:58:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 23:58:03 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.fa719769801b6f0c4297f6513789cc4d@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dmcclean): This would be helpful for one implementation that Bjorn Buckwalter and I are working on for the next generation version of the dimensional library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 10 23:58:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Sep 2014 23:58:16 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.f7622828dbfa334e262bc3592274d644@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:58 jstolarek]: > I thought about it and I believe this should be possible. But we could only infer normal injectivity. I believe an algorithm for inferring injectivity in some of the parameters (ie. things like `result a -> b c` or `result -> b c` for a 3-arity type family) would be exponential in the number of arguments. I don't know anything about this, but what's wrong with exponential time here? This inference only happens once per closed type family, right? How many variables are there likely to be? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 00:01:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 00:01:13 -0000 Subject: [GHC] #9572: nofib target for just building should be part of validate In-Reply-To: <045.5fcdc416d003e87a697cbb6b21514f65@haskell.org> References: <045.5fcdc416d003e87a697cbb6b21514f65@haskell.org> Message-ID: <060.bdd8518737e77976c82d46e988e5d0aa@haskell.org> #9572: nofib target for just building should be part of validate -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib | Version: 7.8.2 benchmark suite | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I haven't been able to make `fibon` or other non-default `nofib` stuff compile at all. It may already be bitrotted, or maybe just docrotted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 00:19:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 00:19:32 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.1550a529633a95264ceed8e65568bad9@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:10 simonpj]: > I can't tell without a concrete example. Can you offer one? Thanks. > > Simon Not yet. Dan Doel's work on Takano Akio's `foldrW/buildW` fusion stuff (with some help from me) shows that it often creates static arguments. It also sometimes leads to apparently-splittable `Rec` groups. I have not ''yet'' seen it create a splittable `Rec` group in which it introduces a static argument. We still don't know if this fusion framework is viable as a replacement for classic `foldr/build`, but it seems likely that giving it a really fair performance test would require a late SAT run of some kind. It may be that there won't be splittable-`Rec` issues, but I figured I'd mention that possibility. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 00:56:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 00:56:07 -0000 Subject: [GHC] #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build In-Reply-To: <045.67b198827318e5a03441f1825701405b@haskell.org> References: <045.67b198827318e5a03441f1825701405b@haskell.org> Message-ID: <060.22594e9cea8516cab1a2c7a0f22e5711@haskell.org> #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): === Progress === Dan Doel has made a lot of progress implementing `foldrW/buildW` versions of major list-processing functions, with a drop of help from me. I've done some work on refactoring and rewrite rules. The `foldM` implementation seems to need the monadic right identity law, `m >>= return = m`, to be implemented in `RULES` in order to get clean Core for the general case (inlining may clean it up at some point for specific instances). I really hope no one is breaking this law. === Challenges === The `buildWForgetful` thing is now fairly clearly the wrong way to go. It seems fine if a "static" producer is tied directly to a pure consumer, but if it's tied to a transformer, bugs go flying everywhere. It therefore seems likely to need some help from the compiler to clean up these static args. The current SAT criterion for what should be transformed is ''not'' sufficient to clean up the static args `foldrW/buildW` sometimes produces. In particular, SAT currently will ''only'' touch functions with at least two static args, which these generally don't. It may be possible to find other criteria for SAT being likely to be good. One particularly obnoxious situation I've seen a couple times is a static argument whose value is actually known at compile time. For example, the "index too large or list empty" error message gets passed around through the recursion in `(!!)`. I don't think preserving that sort of static argument can ''ever'' be good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 04:32:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 04:32:58 -0000 Subject: [GHC] #9574: GHC Panic: No Skolem Info Message-ID: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> #9574: GHC Panic: No Skolem Info -------------------------------------+------------------------------------- Reporter: ian_mi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHC 7.8.3 and from git both panic with Couldn't match kind ?o1? with ?(,) o o? ?o1? is untouchable inside the constraints (Object (c :><: c) a) bound by a type expected by the context: Object (c :><: c) a => Tagged a (c (FMap (ProductF c) a) (FMap (Proj2 c c) a)) at Product.hs:35:9-15ghc: panic! (the 'impossible' happened) (GHC version 7.9.20140908 for x86_64-unknown-linux): No skolem info: o1_a6XS I have not yet attempted to reduce the problem at all. The offending code is the use of fmap here: {{{#!hs proj2 :: forall (c :: o -> o -> *). ProductCategory c => NatTr (c :><: c) c (ProductF c) (Proj2 c c) proj2 = NatTr t where NatTr t = fmap (CompF Proj2 IdentityF) e e :: NatTr (c :><: c) (c :><: c) (Comp ('KProxy :: KProxy o) (Diag c) (ProductF c)) (IdentityF (c :><: c)) e = counit }}} fmap is defined as {{{#!hs fmap :: forall f (a :: o1) (b :: o1). Functor f ('KProxy :: KProxy (o1 -> o2)) => f -> Domain f a b -> Codomain f (FMap f a :: o2) (FMap f b :: o2) fmap _ = proxy morphMap (Proxy :: Proxy f) }}} while CompF is defined by {{{#!hs data CompF f g (k :: KProxy (o3 -> o4, o1 -> o2)) where CompF :: (Functor f ('KProxy :: KProxy (o3 -> o4)), Functor g ('KProxy :: KProxy (o1 -> o2))) => f -> g -> CompF f g ('KProxy :: KProxy (o3 -> o4, o1 -> o2)) }}} This makes some sense because there is a functional dependency between the functor and the kind proxy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 07:48:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 07:48:25 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.eaa8598fd121fb35b91367fe81b2d3e0@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): dmcclean: can you say more precisely what "this" is? There are various designs floating about in this ticket, and comment:14 indicates that the one in the Ticket Description would not solve the problem identified in comment:11. Better still, can you give a concrete, standalone example of what you want/need? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 08:22:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 08:22:04 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.29a05cc6df636a808415db350cac8e81@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): As I mentioned elsewhere, one situation where SAT seems always good is when the static arg is actually available in an outer scope or even statically known. I have seen things that look approximately like this after simplification: {{{#!hs fixedError = error "Bad things!" wfoo x y z = case blah of p1 -> e1 p2 -> wfoo e2 e3 z _ -> z foo x y = wfoo x y fixedError }}} It would seem in this case that instead of having a static argument in place of a closure variable, there's a static argument that just doesn't need to be there at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 08:32:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 08:32:45 -0000 Subject: [GHC] #9574: GHC Panic: No Skolem Info In-Reply-To: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> References: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> Message-ID: <060.0c9d69a240aa18352d90576844e7605a@haskell.org> #9574: GHC Panic: No Skolem Info -------------------------------------+------------------------------------- Reporter: ian_mi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Old description: > GHC 7.8.3 and from git both panic with > > Couldn't match kind ?o1? with ?(,) o o? > ?o1? is untouchable > inside the constraints (Object (c :><: c) a) > bound by a type expected by the context: > Object (c :><: c) a => > Tagged a (c (FMap (ProductF c) a) (FMap (Proj2 c c) > a)) > at Product.hs:35:9-15ghc: panic! (the 'impossible' happened) > (GHC version 7.9.20140908 for x86_64-unknown-linux): > No skolem info: o1_a6XS > > I have not yet attempted to reduce the problem at all. The offending code > is the use of fmap here: > > {{{#!hs > proj2 :: forall (c :: o -> o -> *). ProductCategory c => NatTr (c :><: c) > c (ProductF c) (Proj2 c c) > proj2 = NatTr t where > NatTr t = fmap (CompF Proj2 IdentityF) e > e :: NatTr (c :><: c) (c :><: c) (Comp ('KProxy :: KProxy o) (Diag c) > (ProductF c)) (IdentityF (c :><: c)) > e = counit > }}} > > fmap is defined as > > {{{#!hs > fmap :: forall f (a :: o1) (b :: o1). Functor f ('KProxy :: KProxy (o1 -> > o2)) => f -> Domain f a b -> Codomain f (FMap f a :: o2) (FMap f b :: o2) > fmap _ = proxy morphMap (Proxy :: Proxy f) > }}} > > while CompF is defined by > > {{{#!hs > data CompF f g (k :: KProxy (o3 -> o4, o1 -> o2)) where > CompF :: (Functor f ('KProxy :: KProxy (o3 -> o4)), Functor g > ('KProxy :: KProxy (o1 -> o2))) => > f -> g -> CompF f g ('KProxy :: KProxy (o3 -> o4, o1 -> o2)) > }}} > > This makes some sense because there is a functional dependency between > the functor and the kind proxy. New description: GHC 7.8.3 and from git both panic with {{{ Couldn't match kind ?o1? with ?(,) o o? ?o1? is untouchable inside the constraints (Object (c :><: c) a) bound by a type expected by the context: Object (c :><: c) a => Tagged a (c (FMap (ProductF c) a) (FMap (Proj2 c c) a)) at Product.hs:35:9-15ghc: panic! (the 'impossible' happened) (GHC version 7.9.20140908 for x86_64-unknown-linux): No skolem info: o1_a6XS }}} I have not yet attempted to reduce the problem at all. The offending code is the use of fmap here: {{{#!hs proj2 :: forall (c :: o -> o -> *). ProductCategory c => NatTr (c :><: c) c (ProductF c) (Proj2 c c) proj2 = NatTr t where NatTr t = fmap (CompF Proj2 IdentityF) e e :: NatTr (c :><: c) (c :><: c) (Comp ('KProxy :: KProxy o) (Diag c) (ProductF c)) (IdentityF (c :><: c)) e = counit }}} fmap is defined as {{{#!hs fmap :: forall f (a :: o1) (b :: o1). Functor f ('KProxy :: KProxy (o1 -> o2)) => f -> Domain f a b -> Codomain f (FMap f a :: o2) (FMap f b :: o2) fmap _ = proxy morphMap (Proxy :: Proxy f) }}} while CompF is defined by {{{#!hs data CompF f g (k :: KProxy (o3 -> o4, o1 -> o2)) where CompF :: (Functor f ('KProxy :: KProxy (o3 -> o4)), Functor g ('KProxy :: KProxy (o1 -> o2))) => f -> g -> CompF f g ('KProxy :: KProxy (o3 -> o4, o1 -> o2)) }}} This makes some sense because there is a functional dependency between the functor and the kind proxy. -- Comment (by simonpj): Clearly a bug, but there's virtually no chance of fixing it without a way to reproduce it, alas. So if you felt able to do that, it'd be great. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 12:43:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 12:43:18 -0000 Subject: [GHC] #9575: -XAutoDeriveTypeable fails to generate instances Message-ID: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> #9575: -XAutoDeriveTypeable fails to generate instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following doesn't compile with GHC 7.8.3, but works with GHC HEAD. I couldn't find a matching ticket, so I don't know if this was fixed knowingly or not... {{{#!hs {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable (Typeable) data T1 = C1 Int deriving (Eq,Ord) tvoid :: Typeable a => a -> IO () tvoid _ = return () main :: IO () main = tvoid (C1 0) }}} ...fails for GHC 7.8.3 with {{{ No instance for (Typeable T1) arising from a use of ?tvoid? In the expression: tvoid (C1 0) In an equation for ?main?: main = tvoid (C1 0) }}} I'm marking this with high priority, as it makes `-XAutoDeriveTypeable` unusable on GHC 7.8.3 as it stands. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 13:33:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 13:33:41 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.ed629222a7d99783ba48cf2319e5b72f@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dmcclean): Yes, my apologies Simon. This is actually going to be an interesting example, perhaps, because I learned something about this since yesterday when I wrote that comment. This example is slightly longer than I would like, I'm eliding a few things but I'm not sure exactly which details (e.g. the data family being associated) matter. {{{ class KnownVariant (var :: Variant) where -- | A dimensional value, either a 'Quantity' or a 'Unit', parameterized by its 'Dimension' and representation. data Dimensional var :: Dimension -> * -> * -- elided: some functions to allow us to introduce and eliminate the quantities or units instance KnownVariant DQuantity where newtype Dimensional DQuantity d v = Quantity' v deriving (Eq, Ord, Enum) -- elided: function implementations instance KnownVariant (DUnit p) where data Dimensional (DUnit p) d v = Unit' UnitName v -- elided: function implementations data Variant = DQuantity | DUnit Prefixability type Quantity = Dimensional DQuantity type Unit p = Dimensional (DUnit p) }}} So I set up all that machinery, and then I was curious whether we could `coerce` in and out of the `Dimensional DQuantity d` newtype. So I thought that the way to find out was by asking GHCi what the role of `Dimensional` was. In concept it's `nominal phantom representational`, but it would be extremely complicated for the compiler to see that because it would have to examine all the (both the) instances and so forth, so I didn't know what to expect. {{{ Numeric.Units.Dimensional.DK> :i Dimensional class KnownVariant (var :: Variant) where type role Dimensional nominal nominal nominal data family Dimensional (var :: Variant) ($a :: Dimension) $b ... }}} So I read that, and thought that it meant we were out of luck. But, unexpectedly to me, but undoubtedly for a reason that is quite obvious to someone, and this is the part I only discovered last night: {{{ > let x = 3.7 :: Double > x 3.7 > let y = (coerce x) :: Mass Double > y 3.7 kg > let x' = (coerce y) :: Double > x' 3.7 }}} Somehow it even seems to be OK when you abstract over the dimension with RankNTypes, which isn't really a need but is just something I thought to investigate to see if that was the difference between my expectation of how this would work and how it in fact did work. {{{ > let f = coerce :: (forall d.Double -> Quantity d Double) > (f 3) :: Mass Double 3.0 kg }}} In conclusion, I now believe that I was too hasty yesterday, and that in fact this ticket doesn't impact me at all. My sincere apologies to everyone copied on this ticket. If someone happened to have the time and knew the answer, it would be awesome if you you could help me fix my understanding about whether this should or shouldn't work and what the interplay with roles is, but otherwise I will merrily go about my business. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 13:43:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 13:43:54 -0000 Subject: [GHC] #9575: -XAutoDeriveTypeable fails to generate instances In-Reply-To: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> References: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> Message-ID: <057.7e7958c6c64d65b550d71bd08f45b73e@haskell.org> #9575: -XAutoDeriveTypeable fails to generate instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dreixel): * owner: => dreixel Comment: Removing `deriving (Eq,Ord)` makes it compile. I'll have a closer look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 13:46:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 13:46:08 -0000 Subject: [GHC] #9575: -XAutoDeriveTypeable fails to generate instances In-Reply-To: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> References: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> Message-ID: <057.91a0883fd1a55eac9e5d084d40083979@haskell.org> #9575: -XAutoDeriveTypeable fails to generate instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): See ticket:8950#comment:3. I don't see what there is to gain by backporting a fix though, even if you could detect GHC 7.8.4, it's still more effort to do so than to just add `Typeable` to the deriving list. And it could break old code that uses `AutoDeriveTypeable`, by causing it to export more instances than it did under 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 14:06:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 14:06:15 -0000 Subject: [GHC] #9575: -XAutoDeriveTypeable fails to generate instances In-Reply-To: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> References: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> Message-ID: <057.9ff71d3448975bf59738d8a1b5eae39f@haskell.org> #9575: -XAutoDeriveTypeable fails to generate instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): It sounds to me like this ticket is mostly about making sure the necessary validation tests are in place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 15:29:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 15:29:20 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.0ac3c0ff2effc78887ba7b1b890380bc@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9421 | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by jpmasseria): After I manually deleted `libraries/dph` I now get: {{{ configure: error: in `/home/johnma/ghc/libraries/terminfo': configure: error: curses headers could not be found, so this package cannot be built See `config.log' for more details make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 }}} Should I just start over and re-clone from git? (I'm going to try that). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 16:09:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 16:09:41 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.f5db5162a698fb3364563bdf1a134551@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): I have spent most of this afternoon writing up some thoughts about StaticPtr and serialisation. Here is the result: [blog:simonpj/StaticPointers] I would be very interested in your thoughts. Special thanks to Neil Mitchell who put up with several hours of blather on the way home from ICFP. I did this by writing something new, rather than by editing [wiki:StaticPointers], because I didn't want to Utterly Rewrite the latter. For now you can compare the two. Ultimately we should combine them. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 16:59:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 16:59:43 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.54765ad30fc3df63673a212ec1c88768@haskell.org> #8199: Get rid of HEAP_ALLOCED -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: 5435 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D207 | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => D207 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 17:42:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 17:42:12 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.75024c3932033f1b530051f875d8d1fc@haskell.org> #8199: Get rid of HEAP_ALLOCED -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: 5435 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D207 | -------------------------------------+------------------------------------- Comment (by ezyang): So, here's the status: I rebased the patches onto HEAD, and took a close look at the oscillating results. As it turns out, at least for cryptarithm, the nofib test had bimodal output behavior, so depending on your luck, you'd end up with even changes, or an improvement or a regression. (I think this may be what's happening for the inconsistent GC results; more investigation necessary.) The increase in total memory for cryptarithm1 and circsim stems from the fact that the binaries don't use much memory to begin with, so the allocation of static closures is causing us to allocate a new megablock and, e.g., doubling it in the case cryptarithm. The startup time for GHC is still 0.020, so same as before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 18:05:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 18:05:14 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.54a800426aef0aee07aa58840f84b22b@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8718 Type of failure: | Related Tickets: #2110 None/Unknown | Test Case: | tests/simplCore/should_run/T2110.hs| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dmcclean): I'm out of my depth here, not even sure this thread is about what I'm running in to. I want to coerce from `f (Quantity d v)` to `f v` where `f` is a functor, so that I can add up all the values without their wrappers in the way and then wrap the answer. This works a charm if I specialize `f` to `[]`, but doesn't compile ("because 'f (Quantity d v)' and 'f v' are different types") in the polymorphic version. (Full function below.) {{{ sum :: forall f d v.(Num v, Foldable f, Functor f) => f (Quantity d v) -> Quantity d v sum = coerce . Data.Foldable.sum . (\x -> x :: f v) . coerce sum :: forall d v.(Num v) => [Quantity d v] -> Quantity d v sum = coerce . F.sum . (\x -> x :: [v]) . coerce }}} Is this thread about making a workaround for that? Is the reason that it's complicated because some functors have nominal roles? (Maybe a SortedList would break if you changed out `Ord` instances under it?) Or is there more to it than that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 18:09:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 18:09:15 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.02e2860d1af5021917749918be599fed@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8718 Type of failure: | Related Tickets: #2110 None/Unknown | Test Case: | tests/simplCore/should_run/T2110.hs| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > Is this thread about making a workaround for that? No. Or, not mainly. > Is the reason that it's complicated because some functors have nominal roles? (Maybe a SortedList would break if you changed out Ord instances under it?) Or is there more to it than that? Precisely: We don?t know about the roles of type variables, so we cannot lift coercions through them. I believe that a subsequent design of the system that will be able to cope with Monad?s `join` might be able to handle that, but I?m not up on that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 18:19:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 18:19:41 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.3c57323a098415a20500537e167d0057@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8718 Type of failure: | Related Tickets: #2110 None/Unknown | Test Case: | tests/simplCore/should_run/T2110.hs| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dmcclean): Could the compiler always generate `(Functor f, Coercible a b) => Coercible f a -> Coercible f b` instances that magically either `fmap coerce` or `coerce` depending on the role of f's parameter? Wouldn't the concrete type of `f` be known by the time it came around to generating the instance? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 18:23:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 18:23:45 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.617a6f9a013c5545b79563383a456041@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9421 | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by cetu86): You don't need to start over. You just need ncurses. I downloaded ncurses and cross compiled it for arm, then put it in the cross-tools' sysroot directory under sysroot/usr. Or I guess you could just copy ncurses from your existing installation on your raspberry pi. That way you can be sure you got the right version. Cause when you create dynamically linked executable, you have to have matching versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 18:43:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 18:43:12 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.e83381a843af6b6e55f3b923acfc1050@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1241, #2247, None/Unknown | #8356, #9103, #9227 Test Case: | Blocking: | Differential Revisions: Phab:D69 | -------------------------------------+------------------------------------- Comment (by syallop): Replying to [comment:46 neo]: > Hi! I'm not sure if I face the same problem as the issue author or if my code is just "wrong" but when testing my code with GHC 7.8 I get the [https://travis-ci.org/adp-multi/adp-multi/jobs/34132805#L437 same error] while it worked with 7.6. I believe you do. I can confirm that your code compiles with -XDysfunctionalDependencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 18:56:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 18:56:39 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.da0d4731b5ed1bdba5f56f8acbb30c6f@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1241, #2247, None/Unknown | #8356, #9103, #9227 Test Case: | Blocking: | Differential Revisions: Phab:D69 | -------------------------------------+------------------------------------- Comment (by emertens): Replying to [comment:46 neo]: Your instance `instance Parseable EPS a EPS` fails to satisfy the function dependency `p -> a b` because the `a` can not be determined from `EPS`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 19:02:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 19:02:16 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.c148a97b7351eae2b4871dafceae91d4@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8718 Type of failure: | Related Tickets: #2110 None/Unknown | Test Case: | tests/simplCore/should_run/T2110.hs| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): dmcclean: Note: such a `RULE` is predicated on your `Functor` actually being lawful as well as having a representational argument. (It'd also result in `Coercible (f a) (f b)`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 19:49:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 19:49:33 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.a8389e41c5d06ab20caaa4764414bf9a@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8718 Type of failure: | Related Tickets: #2110 None/Unknown | Test Case: | tests/simplCore/should_run/T2110.hs| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dmcclean): I knew about the representational parameter part, that's why I thought maybe it was possible to only generate the instance if `f` has a representational parameter. i.e. it's not one once-and-for-all instance for all functors, instead it's "magically" (as the current coercible instances are) generated once at each functor type with the branching between `fmap coerce` and `coerce` happening after considering the concrete type of `f`. The bit about the lawfulness I had missed. I don't understand how it results in `Coercible (f a) (f b)` with no context, even if it is once-and-for-all and not the magical akin-to-an- axiom-schema way, but I'm sure you're correct. It seems like the unlawful functor desideratum is very difficult to handle because we don't have a way to have a qualified type that is qualified by whether or not the `Functor` is lawful. One possible thing would be to have an {-# UNLAWFUL #-} pragma, and when you are magically generating instances you branch three ways instead of 2. (Possibly such a pragma could allow more aggressive optimizations in other cases too, with an opt out for 'criminals'?) 1) If the role is representational and there's no unlawful pragma, you generate `coerce`. 2) If there's no unlawful pragma, but the role is something other than representational you generate `fmap coerce`. 3) If there's an unlawful pragma, you generate `error "Attempt to coerce through unlawful functor Foo declared at line ..."`, on the grounds that `error` is not pretty, but neither is unlawfulness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 20:09:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 20:09:05 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.30b1233d14978aa05eed857726a9f3db@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1241, #2247, None/Unknown | #8356, #9103, #9227 Test Case: | Blocking: | Differential Revisions: Phab:D69 | -------------------------------------+------------------------------------- Comment (by goldfire): What's the status on this ticket? I'm still eager to see this merged, and other than regression tests, the patch seems to be in decent shape. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 20:13:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 20:13:07 -0000 Subject: [GHC] #9576: -fdefer-type-errors doesn't defer errors from `deriving` Message-ID: <047.d39ce22800a74d81e08df239345f30b3@haskell.org> #9576: -fdefer-type-errors doesn't defer errors from `deriving` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I say {{{#!hs {-# OPTIONS_GHC -fdefer-type-errors #-} data Foo = MkFoo data Bar = MkBar Foo deriving Show }}} I get a type error that there is no instance for `Show Foo`. This error should be deferred. Using standalone-deriving works just fine, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 20:36:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 20:36:34 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.824b5f07ae92f993434692f9eca6c7e6@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Roles for data families (associated or not) cannot be inferred, because they are open. But, theoretically, they can be declared and then checked. That is the subject of this ticket. So, it conceivable to give the roles you ask for. But, you don't seem to need those roles, because you seem interested in coercing in and out of the newtype, not among different instantiations of the newtype. This is possible as long as the newtype constructor (`Quantity'`) is in scope. Roles aren't a part of the story, in your case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 20:39:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 20:39:40 -0000 Subject: [GHC] #9577: String literals are wasting space Message-ID: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (NCG) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For [https://phabricator.haskell.org/D199 D199] I looked into how string literals are compiled down by GHC. On 64-bit OS X, a simple string `"AAA"` turns into assembly: {{{ .const .align 3 .align 0 c38E_str: .byte 65 .byte 65 .byte 65 .byte 0 }}} (And also something that invokes `unpackCString#`, but that isn't relevant here.) (`MkCore.mkStringExprFS` -> `CmmUtils.mkByteStringCLit` -> `compiler/nativeGen/X86/Ppr.pprSectionHeader`.) Note how this: * Is 8 byte aligned. * Is a `.const` section. I can't find any reason why string literals would need to be 8-byte aligned on OS X. There might be a small benefit in performance to read data starting 8-byte aligned, but I doubt doing that for string literals would be a meaningful difference. Assembly from both clang and gcc does not align string literals. The trivial program: {{{#!hs main :: IO () main = return () }}} has almost 5kB of wasted space of padding between all strings the Prelude brings in, built with GHC HEAD. The fact that it is a `.const` section, instead of `.cstring` (https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/Assembler/040-Assembler_Directives/asm_directives.html#//apple_ref/doc/uid/TP30000823-TPXREF127) means duplicate strings aren't shared by the assembler. GHC floats out string literals to the top-level and uses CSE to eliminate duplicates, but that only works in a single modules. Strings shared between different modules end up as duplicate strings in an executable. The same program as above also has ~4kB of wasted space due to duplicate Prelude strings (`"base"` occurs 16 times!). Compared to the total binary size (4MB after stripping), removing this redundant data wouldn't be a big improvement (0.2%), but I still think it can be a worthwile optimization. I think this can be solved quite easily by creating a new section header for literal strings, which is unaligned and of type `.cstring`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 20:39:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 20:39:51 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.5b628bdfa960a0ddda9731e528d012a0@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by xnyhps): * owner: => xnyhps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 20:41:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 20:41:00 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.2769730cd6be03edaf8d36938b608d15@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8718 Type of failure: | Related Tickets: #2110 None/Unknown | Test Case: | tests/simplCore/should_run/T2110.hs| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): dmcclean: I think you want #9123. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 20:46:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 20:46:10 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.e50e923cdfd111851f85529a124a4ae0@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dmcclean): * cc: douglas.mcclean@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 20:52:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 20:52:12 -0000 Subject: [GHC] #9578: Quoting issue in configure.ac Message-ID: <045.51abf4c3113237a495d0f9c59c18c634@haskell.org> #9578: Quoting issue in configure.ac -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Building hour) | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Some ghc invocations in configure.ac are not properly quoted, causing ./configure to spew errors if there are spaces in the path. See attached patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 20:55:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 20:55:48 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.26dd2e3d77a60e429c7569daf56adb7b@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dmcclean): Hmmm. I was concerned there for a second, because actually `Quantity'` won't be in scope for my users. Its not exported from the module because you can use it to do nefarious things. So I thought that my test in GHCi had been insufficiently thorough, because GHCi doesn't respect the export list and lets you get at unexported things for convenience. So I made a new module to try it. {{{ import Numeric.Units.Dimensional.DK.Prelude import Data.Coerce main = do let x = 3.7 :: Double let y = (coerce x) :: Mass Double putStrLn . show $ y -- putStrLn . show $ Quantity' x -- doesn't compile with this line here }}} It works just fine and prints "3.7 m". With the commented line it doesn't compile, complaining that `Quantity'` is (as I intended) not in scope. (If it had been in scope, it would still fail because the dimension is ambiguous, but that's not the point.) So it seems that whether or not the newtype constructor is in scope is not the determining factor here. If it was intended to be, than this may be a bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 21:01:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 21:01:00 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.3a38d78b543f8d976fdf869e73efb938@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): That does look fishy, but I don't see a definition of `Mass` so I can be sure. Do you have a minimal test case, or a way I can check this myself? If so, please post that as a new ticket, as it's only very tangentially related to this one. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 21:09:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 21:09:36 -0000 Subject: [GHC] #9575: -XAutoDeriveTypeable fails to generate instances In-Reply-To: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> References: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> Message-ID: <057.a058fef9326c40fc4a51869b2fc5d313@haskell.org> #9575: -XAutoDeriveTypeable fails to generate instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:2 rwbarton]: > See ticket:8950#comment:3. > > I don't see what there is to gain by backporting a fix though, even if you could detect GHC 7.8.4, it's still more effort to do so than to just add `Typeable` to the deriving list. And it could break old code that uses `AutoDeriveTypeable`, by causing it to export more instances than it did under 7.8.3. How would this break old code (unless orphan instances are involved) by exporting //more// instances? However, at the very least this should be documented (unless it's easy enough to fix) as a known-bug in 7.8.4's manual (should 7.8.4 be ever be released). Or GHC 7.8.4 could even warn when -XAutoDeriveTypeable is used to raise awareness, that it doesn't work as advertised in GHC 7.8, so people don't start using it next year with GHC 7.10 (where it works as intended), and then assume it worked in GHC 7.8 as well. Alas, missing instances like `Typeable` go easily undetected in libraries. And fwiw, you can discriminate GHC 7.8.4 quite easily via Cabal's `if impl(ghc>=7.8.4) ...` conditionals... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 21:11:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 21:11:25 -0000 Subject: [GHC] #9575: -XAutoDeriveTypeable fails to generate instances In-Reply-To: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> References: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> Message-ID: <057.abcbd0783ebd412f1f650747f72763eb@haskell.org> #9575: -XAutoDeriveTypeable fails to generate instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:4 hvr]: > How would this break old code (unless orphan instances are involved) by exporting //more// instances? Yes, I mean with orphan instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 21:28:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 21:28:05 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible Message-ID: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I just ran into a stack overflow in an application, and GHC told me: Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize -RTS' to increase it. I tried to specify +RTS and got an error saying "Most RTS options are disabled. Link with -rtsopts to enable them." The runtime should not suggest using +RTS when that is not possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 21:37:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 21:37:24 -0000 Subject: [GHC] #9580: Possible excessive leniency in interaction between coerce and data families? Message-ID: <047.e05803593a4302846c266dc183138a0f@haskell.org> #9580: Possible excessive leniency in interaction between coerce and data families? -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Per goldfire's request at #8177, I am promoting this issue into it's own ticket. I am entirely not confident that it represents a bug; I raise the issue because, while it happens to do exactly what I want, I cannot understand *why* it does what I want, and it seems like it might possibly also do related undesirable things. I have the following situation, which I have distilled from a real use case, retaining its identifiers but eliding a whole bunch of irrelevant detail. The real thing is on GitHub if it helps anyone to see why I want to do this, but it's really a side issue AFAICT. It's split into two modules, because goldfire had suggested that it might have arisen because the newtype constructor `Quantity'` was in scope at the site of the `coerce`, this test shows that it arises even when `Quantity'` is not in scope. {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module Test ( Quantity, Unit, Dimension(..), Variant(..), Mass, KnownVariant(Dimensional) ) where data Variant = DQuantity | DUnit data Dimension = DMass | DLength | DTime -- ... this isn't the real way, it's simplified data UnitName = UnitName String class KnownVariant (var :: Variant) where data Dimensional var :: Dimension -> * -> * instance KnownVariant DQuantity where newtype Dimensional DQuantity d v = Quantity' v instance KnownVariant DUnit where data Dimensional DUnit d v = Unit' UnitName v instance (Show v) => Show (Dimensional DQuantity d v) where show (Quantity' x) = "As A Quantity " ++ show x type Quantity = Dimensional DQuantity type Unit = Dimensional DUnit type Mass v = Quantity DMass v }}} And the main module: {{{ module Main where import Test import Data.Coerce main = do let x = 3.7 :: Double putStrLn . show $ x let y = (coerce x) :: Mass Double putStrLn . show $ y let z = (coerce y) :: Double putStrLn . show $ z }}} My question is in two parts: 1) Why are these coercions allowed if the role signature of `Dimensional` is, as GHCi's :i tells me, nominal nominal nominal? 2) Is this the intended behavior? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 21:41:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 21:41:38 -0000 Subject: [GHC] #9581: Parse error in multiline case expression inside let inside do block Message-ID: <045.886764c980442ec42afee84380211860@haskell.org> #9581: Parse error in multiline case expression inside let inside do block -------------------------------------+------------------------------------- Reporter: mpopov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{#!hs main = do let x = case 1 of 0 -> False _ -> True print x }}} The above program produces the following error: $ runghc bug.hs bug.hs:3:11: parse error on input ?->? Slightly rewritten versions print True as indended: {{{#!hs main = do let x = case 1 of { 0 -> False; _ -> True } print x main = do print $ case 1 of 0 -> False _ -> True }}} I have double-checked that the offending program does not contain mixed tabs and spaces. The same error occurs on my own system (Linux Mint x64, Haskell Platform 2014.2 with GHC 7.83) and in FPComplete's online IDE. I first encountered the error in a program copied verbatim from a Haskell book, so i assume that the syntax is allowed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 21:54:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 21:54:49 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.e5e3b561f1ef77f31f601d76049d8eab@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): But then how would anyone learn how to increase the stack limit? (Also, isn't the default stack limit set to be most of your RAM already in 7.8? Are you really using ghc 7.9?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 21:58:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 21:58:24 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.b49f20717e89766dd58b4697d110e36d@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): You sound as if you know what you are talking about. I say go for it! But please make sure that whatever you do works on Windows and Linux as well as Mac. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 22:02:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 22:02:48 -0000 Subject: [GHC] #9578: Quoting issue in configure.ac In-Reply-To: <045.51abf4c3113237a495d0f9c59c18c634@haskell.org> References: <045.51abf4c3113237a495d0f9c59c18c634@haskell.org> Message-ID: <060.52c39e0ead137f08533511f84bc11337@haskell.org> #9578: Quoting issue in configure.ac -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 22:03:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 22:03:26 -0000 Subject: [GHC] #9581: Parse error in multiline case expression inside let inside do block In-Reply-To: <045.886764c980442ec42afee84380211860@haskell.org> References: <045.886764c980442ec42afee84380211860@haskell.org> Message-ID: <060.13e583134df82422378c135c135c42e4@haskell.org> #9581: Parse error in multiline case expression inside let inside do block -------------------------------------+------------------------------------- Reporter: mpopov | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: This program isn't valid. `let` introduces layout, so because line 3's first non-whitespace character is in the same column as the first non- whitespace character after the `let`, lines 2-4 desugar to {{{ let { x = case 1 of {}; 0 -> False; _ -> True }; }}} Lines 3 and 4 need to be indented by at least one more space for the intended meaning. (It may help to recall that {{{ main = do let x = 1 y = 2 print x }}} is valid syntax.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 22:13:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 22:13:37 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.3c34372d3a26253da39f2b70ead01d5d@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1241, #2247, None/Unknown | #8356, #9103, #9227 Test Case: | Blocking: | Differential Revisions: Phab:D69 | -------------------------------------+------------------------------------- Comment (by simonpj): Situation is this. In comment:30 I show (using Martin's example) that lifting the liberal coverage condition (which is what `-XDysFunctionalDependencies` proposes to do) means that type inference becomes unpredicatable. On Monday it might succeed, but after a minor change to the order in which constraints are examined, on Tuesday it might fail. This is not a happy situation. I did not realise this when I wrote comment:14. On the other hand, danilo2 (I wish I knew your real name) is saying strongly that `=XDysFunctionalDependencies` would really help him. It is possible that his problem could be solved in some other way, but that would take a serious investment of time to find out, and danilo2 believes not. So what to do? We could treat it like `unsafeCoerce`: you can use it, but then you are on your own. (Maybe it should have an even more discouraging name e.g. `-XUnpredicatbleFunctionalDependencies`.) I worry, though, that people will bump into problems, and submit bug reports, ... Any other opinions? danilo2, are you still arguing for this despite the difficulties? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 22:29:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 22:29:45 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.368f85c522a7124277d87647a9bf3113@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1241, #2247, None/Unknown | #8356, #9103, #9227 Test Case: | Blocking: | Differential Revisions: Phab:D69 | -------------------------------------+------------------------------------- Comment (by danilo2): Hello Simon, Goldfire! Answering your question Simon - my name is Wojciech Dani?o :) The situation you describe is really dangerous. Still - I and some people I'm working with belive that `-XDysfunctionalDependencies` would help us. Even more - this is crutial for the project to work and we are using this flag in very specific situations. But there is one more thing to note about our situation. Right now we are using Haskell as a backend to our language. Some specific features are very hard to reach in Haskell so we are slowly moving over our own type checker and compilation directly to Haskell core. If we succeed, we would not need this extension anymore. But this will not happen in very near future and for now this is crutial for the project we are working on. I would vote for treating `-XDysfunctionalDependencies` as `unsafeCoerce` for now and writing in the documentation that it is very dangerous. This way we can limit incorrect bug reports etc. Do you think it makes sense? Wojciech -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 22:31:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 22:31:11 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.90144370ac6353d253d8f38348ff91d4@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): It sounds like what you'd really like is an extended error message when RTS options are not enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 22:42:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 22:42:45 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.cda8757406887371392bbc24861a1419@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Actually I see one case where not suggesting using +RTS makes sense: when the user has installed a Haskell application like pandoc through their package manager, if it wasn't built with -rtsopts, the suggestion to link with -rtsopts will be rather unhelpful. I suppose we could add an option -no-rtsopts-suggestions and encourage people distributing binaries to build with either -rtsopts or -no-rtsopts- suggestions... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 22:56:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 22:56:46 -0000 Subject: [GHC] #9580: Possible excessive leniency in interaction between coerce and data families? In-Reply-To: <047.e05803593a4302846c266dc183138a0f@haskell.org> References: <047.e05803593a4302846c266dc183138a0f@haskell.org> Message-ID: <062.ba6b4e0436dfd04e6d1646bebfae082f@haskell.org> #9580: Possible excessive leniency in interaction between coerce and data families? -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dmcclean): I tried a bunch of variations to see if I could get this to not compile to see what might be causing it. It still works if you move the type synonym definitions of `Mass` and `Quantity` out of `Test` and into `Main` (as long as you move the language extensions too). It still works even if the last type parameter is held polymorphic, as {{{ f :: Num v => v -> Mass v f x = coerce $ 3 * x }}} even when `f` is defined in `Main`. It even still works if the last two parameters are held polymorphic, as {{{ g :: Num v => v -> Quantity d v g x = coerce $ 3 * x }}} even when `g` is defined in `Main`. It also works if you do the same thing but expand the type synonyms manually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 11 23:31:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Sep 2014 23:31:07 -0000 Subject: [GHC] #9580: Possible excessive leniency in interaction between coerce and data families? In-Reply-To: <047.e05803593a4302846c266dc183138a0f@haskell.org> References: <047.e05803593a4302846c266dc183138a0f@haskell.org> Message-ID: <062.2072d44448974e769077eaa5b0ccc968@haskell.org> #9580: Possible excessive leniency in interaction between coerce and data families? -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Oh yes, this is a real bug. Here is a cut-down test case {{{ {-# LANGUAGE KindSignatures, TypeFamilies #-} module T9580a( Dimensional ) where data family Dimensional var :: * -> * newtype instance Dimensional Int v = Quantity' v ------------------ module T9680 where import T9580a import Data.Coerce foo :: Dimensional Int Double -> Double foo x = coerce x }}} Obviously, the latter module should fail to type check, since `Quantity'` is not in scope. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 00:10:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 00:10:28 -0000 Subject: [GHC] #5289: Can't use ghci with a library linked against libstdc++ In-Reply-To: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> References: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> Message-ID: <057.3e5944cfcd0944727a1bc7f5857fc47b@haskell.org> #5289: Can't use ghci with a library linked against libstdc++ -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ihameed): * cc: idhameed@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 10:09:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 10:09:51 -0000 Subject: [GHC] #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults In-Reply-To: <050.3909a9b5b308161cfebc22d2e86541c4@haskell.org> References: <050.3909a9b5b308161cfebc22d2e86541c4@haskell.org> Message-ID: <065.4526410174d61f12446d7c63204177e6@haskell.org> #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults -------------------------------------------+----------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+----------------------------- Comment (by slyfox): I think it's a manifestation of #8024 (and #8857). Can you try to apply a patch on top of 7.8.3 from https://phabricator.haskell.org/D177 (or just try -HEAD) and see if it helps? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 11:30:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 11:30:04 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.cfaacf16a1628bb5563c03618dc0c9eb@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: | Owner: jjaredsimpson | Status: infoneeded Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: Prelude | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by yalas): I agree with Scott Turner, we can leave {{{x**infinity}}} for another day. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 11:35:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 11:35:17 -0000 Subject: [GHC] #9573: Add warning for invalid digits in integer literals In-Reply-To: <045.6745c955d16114a85008c81a7aea2c4a@haskell.org> References: <045.6745c955d16114a85008c81a7aea2c4a@haskell.org> Message-ID: <060.b15f2b827ac0208c1208e436d5823644@haskell.org> #9573: Add warning for invalid digits in integer literals -------------------------------------+------------------------------------- Reporter: vlopez | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Parser) | Keywords: parsing, integer, Resolution: | octal, binary, hexadecimal, Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: | days) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by vlopez): Here's a partial patch (attachment `invalid-digit-warning-6c9246.patch`), which gives a warning in most cases. However, the feature not very useful when the user for making sense of a type error, as GHC only seems to display warnings when the module can be compiled correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 11:36:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 11:36:34 -0000 Subject: [GHC] #9573: Add warning for invalid digits in integer literals In-Reply-To: <045.6745c955d16114a85008c81a7aea2c4a@haskell.org> References: <045.6745c955d16114a85008c81a7aea2c4a@haskell.org> Message-ID: <060.0a84aed910bce37d33012774f300d572@haskell.org> #9573: Add warning for invalid digits in integer literals -------------------------------------+------------------------------------- Reporter: vlopez | Owner: vlopez Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Parser) | Keywords: parsing, integer, Resolution: | octal, binary, hexadecimal, Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: | days) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by vlopez): * owner: => vlopez Old description: > In its latest version, GHC can parse binary (with `-XBinaryLiterals`), > octal and hexadecimal literals: > > {{{#!hs > > 0b101010 > > 0o52 > > 0x2A > }}} > > Currently, the parser/lexer reads digits from the input as long as they > are valid for the specified radix. All subsequent digits are interpreted > as a new, separate token. > > If the user uses a digit which isn't valid for the radix, it may be > reported with a non-obvious error message, or interpreted in surprising > ways: > > {{{#!hs > > :t 0o567 > 0o576 :: Num a => a > > :t 0o5678 > 0o5678 :: (Num (a -> t), Num a) => t > Prelude> :t 0x1bfah > > :1:7: Not in scope: ?h? > > replicate 0o5678 > [8,8,8,8,8,8,8... > }}} > > We suggest warning the user when a literal of this sort is written, while > respecting any other error messages and the original behaviour. > > More specifically, the parser or lexer would give a warning if a token > starting with an alphanumeric character is found immediately after a > numeric literal, without a blank between them. New description: In its latest version, GHC can parse binary (with `-XBinaryLiterals`), octal and hexadecimal literals: {{{#!hs > 0b101010 > 0o52 > 0x2A }}} Currently, the parser/lexer reads digits from the input as long as they are valid for the specified radix. All subsequent digits are interpreted as a new, separate token. If the user uses a digit which isn't valid for the radix, it may be reported with a non-obvious error message, or interpreted in surprising ways: {{{#!hs > :t 0o567 0o576 :: Num a => a > :t 0o5678 0o5678 :: (Num (a -> t), Num a) => t > :t 0x1bfah :1:7: Not in scope: ?h? > replicate 0o5678 [8,8,8,8,8,8,8... }}} We suggest warning the user when a literal of this sort is written, while respecting any other error messages and the original behaviour. More specifically, the parser or lexer would give a warning if a token starting with an alphanumeric character is found immediately after a numeric literal, without a blank between them. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 11:50:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 11:50:48 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.984ed7353aea3c797df155f44ca9c82f@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1241, #2247, None/Unknown | #8356, #9103, #9227 Test Case: | Blocking: | Differential Revisions: Phab:D69 | -------------------------------------+------------------------------------- Comment (by goldfire): About unpredictability: I think this is quite similar to `IncoherentInstances`, where, I believe, similar unpredictability exists. A notable difference here is that `DysfunctionalDependencies` would introduce compile-time unpredictability. I would say, though, that it is up to the user to make sure that their dysfunctional dependencies are confluent w.r.t. the equivalence relation that is relevant to them -- which might not be `(~)`. So, I think there's support for this feature. What needs to be done to merge? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 12:17:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 12:17:23 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.29ddd912dacecccaabc0143420ed2b31@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1241, #2247, None/Unknown | #8356, #9103, #9227 Test Case: | Blocking: | Differential Revisions: Phab:D69 | -------------------------------------+------------------------------------- Comment (by simonpj): OK, fine, let's do it. Perhaps Wojciech can address my comments in Prabricator. And add a couple of regression tests, culled from this ticket. Most important, I think the user manual needs a sub-section explaining the consequences of `DysFunctionalDependencies`, with pointers to further details (e.g. this ticket). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 12:25:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 12:25:56 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs Message-ID: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: InstanceSigs | Unknown/Multiple TypeFamilies | Type of failure: Architecture: Unknown/Multiple | None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE InstanceSigs, TypeFamilies #-} class C a where type T a m :: T a instance C Int where type T Int = String m :: String m = "bla" -- Method signature does not match class; it should be m :: T Int -- In the instance declaration for ?C Int? }}} As {{{T Int}}} is a synonym of {{{String}}}, {{{m :: String}}} should be a valid type signature alternative to {{{m :: T Int}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 12:53:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 12:53:20 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD Message-ID: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Steps to reproduce: 1. Clone Cabal HEAD 2. `cabal configure --with-ghc=/path/to/ghc-head` 3. `dist/setup/setup build` Actual results: {{{ [ 8 of 78] Compiling Distribution.Text ( Distribution/Text.hs, dist/build/Distribution/Text.o ) [ 9 of 78] Compiling Distribution.Version ( Distribution/Version.hs, dist/build/Distribution/Version.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20140911 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone GHC.Word.$fNumWord8_$c+ To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 813720 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I know that it still fails with tick factor 4096; I haven't found a tick amount which makes it succeed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 13:11:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 13:11:12 -0000 Subject: [GHC] #9575: -XAutoDeriveTypeable fails to generate instances In-Reply-To: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> References: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> Message-ID: <057.0ada145afbeb818d141db3b51b193a5f@haskell.org> #9575: -XAutoDeriveTypeable fails to generate instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T8950 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dreixel): * testcase: => deriving/should_compile/T8950 Comment: `deriving/should_compile/T8950` already tests for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 13:15:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 13:15:59 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.1a33a92cd028804f329a4ac4c7514dd8@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): How do I "clone Cabal Head"? Perhaps {{{ git clone http://git.haskell.org/packages/Cabal.git }}} Just want to be sure we are talking about the same thing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 13:20:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 13:20:09 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.72081aa3e16b6b9de4c13f1a0af3f5fa@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): Sorry, use the GitHub repo: {{{ git clone http://github.com/haskell/cabal.git }}} It also fails at tick factor 8192, and ran out of memory for me on the next power of two. Probably an infinite loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 14:50:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 14:50:16 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.30b5eb31674ba30f31e1512ec788fc25@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: highest => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 15:04:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 15:04:35 -0000 Subject: [GHC] #7567: invalidateModSummaryCache throws exception if ms_hs_date is 0 In-Reply-To: <044.528a24a412eb29535dc4aa70b74720f6@haskell.org> References: <044.528a24a412eb29535dc4aa70b74720f6@haskell.org> Message-ID: <059.167221bfe171b57ad00c7ba775df3a13@haskell.org> #7567: invalidateModSummaryCache throws exception if ms_hs_date is 0 -------------------------------------+------------------------------------- Reporter: edsko | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 15:09:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 15:09:40 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.a292dbfda8389a3807fb5cd41e1e35b1@haskell.org> #8276: Building Haddock documentation panics with perf build on x86_64 Linux -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: | Version: 7.7 Documentation | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 15:31:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 15:31:19 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.3ee6d1d3ddf97c34f85855c374a737ca@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1241, #2247, None/Unknown | #8356, #9103, #9227 Test Case: | Blocking: | Differential Revisions: Phab:D69 | -------------------------------------+------------------------------------- Comment (by danilo2): Simon, I would love to and I would do it. I just need some help - if anybody could give me some informations - where are these regression tests and what exactly should I add, I would do it with pleasure :) I was looking for it for a limited time (because of huge amount of work) but with some tips I will add them as fast as possible :) Help with writing this documentation section would also be needed - especially when talking about consequences according to how GHC works internally. Wojciech -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 16:02:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 16:02:10 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.50e27710af8d6ac7751c131540af8221@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by danilo2): Hello! Is there any patch which would allow me to use injective type families in current GHC? I saw on the top of this page, that a patch was provided, but about 2 years ago - are there any working implementations? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 16:17:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 16:17:16 -0000 Subject: [GHC] #9584: Interface file errors (Iface type variable out of scope: k) Message-ID: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> #9584: Interface file errors (Iface type variable out of scope: k) -------------------------------------+------------------------------------- Reporter: jonsterling | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (Please forgive me if I have not formatted this bug report properly) Anyway, yesterday in a project at work we started having a strange problem where pretty much any change in our code at all would result in the next build failing with this error: {{{ The interface for ?main:HList? Declaration for $fRLensk:r_$s$w$crlens: Iface type variable out of scope: k Cannot continue after interface file error }}} I can get around the problem by deleting the dist directory, but this is very unfortunate, since it basically changes my build/test cycle from a few seconds to a minutes because I can't take advantage of the cached builds of things that *haven't* changed. It seems like errors like this have cropped up a few times in GHC, but they've always been fixed so far, so hopefully someone here will be familiar with what is causing this one! Please let me know if there is further information I can provide. The file in question looks basically like this: (it depends on some other stuff in our project, and so it won't build immediately if you paste it onto your machine; let me know if you need me to bundle it up into something self-contained). {{{#!hs -- | A bespoke record/HList type. 'el' interprets fields into types; 'tot' is -- the maximal extension of the record type; and 'rs' is the subset of 'tot' -- contained in the record itself. data Record (el :: k -> *) (tot :: [k]) (rs :: [k]) where Nil :: Record el tot '[] (:*) :: ( ElemTF r tot ?? '("the key", r, "is not permitted in this record, which may only contain", tot) , DistinctTF (r ': rs) ?? '("the key", r, "is already in", rs) ) => el r -> Record el tot rs -> Record el tot (r ': rs) infixr 9 :* -- | Records have lenses for their fields. class ElemTF r rs ~ True => RLens rs r where rlens :: proxy r -> CL.Lens' (Record el tot rs) (el r) instance RLens (r ': rs) r where rlens _ = CL.lens (\(x :* _) -> x) (\(_ :* xs) x -> x :* xs) instance (ElemTF r (s ': rs) ~ True, RLens rs r) => RLens (s ': rs) r where rlens _ = CL.lens (\(_ :* xs) -> xs ^. rlens Proxy) (\(x :* xs) y -> x :* xs & rlens Proxy .~ y) -- | Records with fields in 'K' give rise to a functor from 'Hask^K' to 'Hask'. (<<$>>) :: (forall x. f x -> g x) -> Record f tot rs -> Record g tot rs _ <<$>> Nil = Nil eta <<$>> (x :* xs) = eta x :* (eta <<$>> xs) infixl 8 <<$>> -- | Records can be traversed to pull out some of their effects. rtraverse :: Applicative h => (forall x. f x -> h (g x)) -> Record f tot rs -> h (Record g tot rs) rtraverse _ Nil = pure Nil rtraverse f (x :* xs) = (:*) <$> f x <*> rtraverse f xs -- | As a special case, we can yank out the first layer of effects in a -- composed functor stack. rtraverse1 :: Applicative f => Record (f :. g) tot rs -> f (Record g tot rs) rtraverse1 = rtraverse getCompose -- | Records whose fields are uniform in type may be turned into a list. recordToList :: Record (Const t) tbl rs -> [t] recordToList Nil = [] recordToList (Const x :* xs) = x : recordToList xs instance Show (Record el tot '[]) where show _ = "Nil" instance ( Show (Record el tot rs) , Show (el r) ) => Show (Record el tot (r ': rs)) where show (x :* xs) = "(" ++ show x ++ " :* " ++ show xs ++ ")" data family Sing (a :: k) class SingI a where sing :: Sing a class kparam ~ Any => SingE (kparam :: k) rep | kparam -> rep where fromSing :: Sing (a :: k) -> rep }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 16:44:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 16:44:42 -0000 Subject: [GHC] #9563: Support for deriving Generic1 for data families In-Reply-To: <047.5afce0493774ce2d5de4e9e316ca0dec@haskell.org> References: <047.5afce0493774ce2d5de4e9e316ca0dec@haskell.org> Message-ID: <062.eace870d17f77a0959c7fa0e33ce94be@haskell.org> #9563: Support for deriving Generic1 for data families -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Jose Pedro Magalhaes ): In [changeset:"946cbcefab9bc02e12b741e5b070d7521b37ba1a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="946cbcefab9bc02e12b741e5b070d7521b37ba1a" Fix support for deriving Generic1 for data families (FIX #9563) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 16:46:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 16:46:24 -0000 Subject: [GHC] #9563: Support for deriving Generic1 for data families In-Reply-To: <047.5afce0493774ce2d5de4e9e316ca0dec@haskell.org> References: <047.5afce0493774ce2d5de4e9e316ca0dec@haskell.org> Message-ID: <062.80df5759db530a289e84b372426c09f9@haskell.org> #9563: Support for deriving Generic1 for data families -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: dreixel Type: bug | Status: merge Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: generics/T9563 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dreixel): * status: new => merge * testcase: => generics/T9563 Comment: Thanks for reporting. That code now compiles with HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 16:54:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 16:54:25 -0000 Subject: [GHC] #9584: Interface file errors (Iface type variable out of scope: k) In-Reply-To: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> References: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> Message-ID: <065.9bea7b801bd1545782b34a7a37b734c5@haskell.org> #9584: Interface file errors (Iface type variable out of scope: k) -------------------------------------+------------------------------------- Reporter: | Owner: jonsterling | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Looks bogus to me. Can you create a reproducible test case, as self- contained as possible? Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 16:58:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 16:58:36 -0000 Subject: [GHC] #9580: Possible excessive leniency in interaction between coerce and data families? In-Reply-To: <047.e05803593a4302846c266dc183138a0f@haskell.org> References: <047.e05803593a4302846c266dc183138a0f@haskell.org> Message-ID: <062.c8b3ee2180329bb9f1ac8f59e60ec1ad@haskell.org> #9580: Possible excessive leniency in interaction between coerce and data families? -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm on this (refactoring...), but am now out of action till Tues. SImon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 17:01:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 17:01:20 -0000 Subject: [GHC] #9584: Interface file errors (Iface type variable out of scope: k) In-Reply-To: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> References: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> Message-ID: <065.3635db776f4cd226d10688807d5774b1@haskell.org> #9584: Interface file errors (Iface type variable out of scope: k) -------------------------------------+------------------------------------- Reporter: | Owner: jonsterling | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thoughtpolice): FWIW, this looks quite similar to #9263. If you *can* boil this down at all to be a small self contained set of modules, that'd be great; I'd be willing to test if the fix for #9263 also fixes this (and if so, we can add this example as another test). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 17:02:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 17:02:31 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.10f56aa64b87dbe9ff245da7c465a5c1@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:22 dmcclean]: > Hmmm. > > I was concerned there for a second, because actually `Quantity'` won't be in scope for my users. Its not exported from the module because you can use it to do nefarious things. BTW I'm confused by this comment, because the things you can do with `Quantity'` are just the things you can do with `coerce`, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 17:05:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 17:05:46 -0000 Subject: [GHC] #9584: Interface file errors (Iface type variable out of scope: k) In-Reply-To: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> References: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> Message-ID: <065.4c26df165f4edfab861e3710d86d529d@haskell.org> #9584: Interface file errors (Iface type variable out of scope: k) -------------------------------------+------------------------------------- Reporter: | Owner: jonsterling | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jonsterling): Hi Simon! Not sure what you could mean by "bogus", but Austin Seipp's suggested me that this seems similar to #9253... I'll try and bundle this up into something testable as soon as possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 17:09:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 17:09:16 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.134873379fc6b0c710f244865b84b97c@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dmcclean): Yes. I was badly confused when I wrote that comment, sorry. See 9580 for where I broke this out as requested by goldfire. It turns out that the rule is indeed supposed to be that you can only do this coercion when `Quantity'` is in scope, which makes sense because that is when you could do it longhand, but that 7.8.3 currently implements a more lenient unintentional rule that also lets you do it (at least sometimes?) when you only have the data family in scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 17:42:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 17:42:45 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.4596ae366c213506915956f07f55354f@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9421 | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by jpmasseria): Replying to [comment:23 cetu86]: Thanks for the continued help. I'm still stuck where my GHC build doesn't find ncurses. I have done the following (my main issue is that I don't really understand where I need to "install" my cross compiled version of ncurses. {{{ wget ftp.de.debian.org/debian/pool/main/n/ncurses/ncurses_5.9.orig.tar.gz tar xf ncurses_5.9.orig.tar.gz cd ncurses-5.9/ ./configure --target=arm-linux-gnueabihf --with-gcc=arm-linux- gnueabihf-gcc --target=arm-linux-gnueabihf --prefix=/home/johnma/arm- linux-gnueabihf make && make install }}} As I understand it this placed the cross compiled `ncurses` into my directory `/home/johnma/arm-linux/gnueabihf` I then tried to build GHC using this as follows: {{{ cd ../ghc/ ./configure --target=arm-linux-gnueabihf --enable-unregisterised --with-gcc=`which arm-linux-gnueabihf-gcc` --with-nm=/usr/bin/nm --with- sysroot=/home/johnma/arm-linux-gnueabihf make -j2 }}} Needless to say that achieved the same ncurses not found error. Again, my confusion is how I tell the GHC build to find this ncurses. Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 18:10:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 18:10:50 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.f33783b6dc3ab7b61eed2f6bc8e4920a@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:2 ezyang]: > UPDATE: I just checked, both should work. that's because github's master branch is automatically mirrored to our git.haskell.org copy of Cabal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 18:21:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 18:21:06 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.f44744c600f44faa969b296bbb725bb7@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1241, #2247, None/Unknown | #8356, #9103, #9227 Test Case: | Blocking: | Differential Revisions: Phab:D69 | -------------------------------------+------------------------------------- Comment (by goldfire): This [wiki:Building/RunningTests/Adding wiki page] tells you how to add test cases. As for documentation, you should edit `docs/users_guide/glasgow_exts.xml`. The format there is that for DocBooks, but it's easy enough just to parrot the code that's in there. Is this enough guidance? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 19:33:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 19:33:20 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.59a597aac4688ace33bc303b552a3f11@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): I wonder if #9565 is of the same cause (smaller source file, but nastier). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 19:47:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 19:47:36 -0000 Subject: [GHC] #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux In-Reply-To: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> References: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> Message-ID: <062.5eca57dac20ea5920e35ac804cb28f6a@haskell.org> #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux ----------------------------------------------+--------------------------- Reporter: chrisfgl | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8976 Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by rwbarton): The patch for #9439 isn't on the ghc-7.8 branch, but it seems to apply cleanly, so you can try making a clone of ghc-7.8, `git cherry-pick 5895f2b8ffba72a8393e9f712461e6e5ed7ceced` and then build as usual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 19:51:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 19:51:17 -0000 Subject: [GHC] #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build In-Reply-To: <045.67b198827318e5a03441f1825701405b@haskell.org> References: <045.67b198827318e5a03441f1825701405b@haskell.org> Message-ID: <060.589463d9f3a71dcf27b37b1d36141627@haskell.org> #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => wontfix Comment: Challenges seem to be piling up. The biggest problem is that no one has been able to find local criteria to ensure correctness. The interesting wrappers don't generally satisfy the trivial `wrap . unwrap = id` correctness condition; rather, they rely on more complex interactions with the loop bodies they're embedded in. To ensure correctness, we would need two things: 1. Rules about how a producer can/must use the wrapper, cons, and nil it receives, and 2. Rules about what properties the wrapper, cons, and nil a consumer uses must have to ensure correct behavior when used by a sufficiently well- behaved producer. In essence, these three things have to travel and transform ''together'' in a correct fashion as they travel from a consumer through transformers to a producer. Takano Akio did not write any such things down, and Joachim was unable to make contact. Joachim and Dan couldn't think of anything. Edward K. said this whole thing looked frightening. It may be that one of the wizards out there can come up with a way to make this work, but until then, I think it's probably best to set it aside. Joachim has some other ideas for addressing the underlying issues; hopefully one of them will work out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 20:03:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 20:03:18 -0000 Subject: [GHC] #9565: T3500b exhaust simplifier ticks (loops?) on WAY=optasm In-Reply-To: <045.21253a4eab836dbd85b1b13d4815a773@haskell.org> References: <045.21253a4eab836dbd85b1b13d4815a773@haskell.org> Message-ID: <060.77b1edf0af15b9676a59c35ba4e423b0@haskell.org> #9565: T3500b exhaust simplifier ticks (loops?) on WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: T3500b | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): could this be an instance of the known issue about recursive types interacting with the inliner? https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/bugs.html see the second item there if i change the program to {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts, UndecidableInstances #-} module Main where newtype Mu f = Mu (f (Mu f)) type family Id m type instance Id m = m instance Show (Id (f (Mu f))) => Show (Mu f) where show (Mu f) = show f {-# NOINLINE show #-} showMu :: Mu (Either ()) -> String showMu = show item :: Mu (Either ()) item = Mu (Right (Mu (Left ()))) main = print (showMu item) }}} that is, I mark the show instance NOINLINE, the problem goes away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 20:52:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 20:52:57 -0000 Subject: [GHC] #9585: Note about semantics of (!!) is not specific enough, if it's correct Message-ID: <045.8790a8448bdb789c8c5b48af4e4acadc@haskell.org> #9585: Note about semantics of (!!) is not specific enough, if it's correct -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The definition of `(!!)` in `GHC.List`, copied below, has a vague note about semantics for the Prelude and HBC versions being different. I can't see the difference myself. If there really is a difference, the details should be in the comment. {{{#!hs -- | List index (subscript) operator, starting from 0. -- It is an instance of the more general 'Data.List.genericIndex', -- which takes an index of any integral type. (!!) :: [a] -> Int -> a #ifdef USE_REPORT_PRELUDE xs !! n | n < 0 = error "Prelude.!!: negative index" [] !! _ = error "Prelude.!!: index too large" (x:_) !! 0 = x (_:xs) !! n = xs !! (n-1) #else -- HBC version (stolen), then unboxified -- The semantics is not quite the same for error conditions -- in the more efficient version. -- xs !! (I# n0) | isTrue# (n0 <# 0#) = error "Prelude.(!!): negative index\n" | otherwise = sub xs n0 where sub :: [a] -> Int# -> a sub [] _ = error "Prelude.(!!): index too large\n" sub (y:ys) n = if isTrue# (n ==# 0#) then y else sub ys (n -# 1#) #endif }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 21:14:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 21:14:05 -0000 Subject: [GHC] #9585: Note about semantics of (!!) is not specific enough, if it's correct In-Reply-To: <045.8790a8448bdb789c8c5b48af4e4acadc@haskell.org> References: <045.8790a8448bdb789c8c5b48af4e4acadc@haskell.org> Message-ID: <060.8843976e64751b033617feed1b272054@haskell.org> #9585: Note about semantics of (!!) is not specific enough, if it's correct -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: After staring at the code for a few minutes, I also don?t see a difference ? both evaluate `n` first, and then go down the list in the obvious manner. Some archaeology reveals: ceb68b9118fa883e88abfaa532fc78f6640cf17f changed the prelude definition, and before the change, `!!` would evaluate the list before the number. So you are right, the comment is wrong. I just removed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 21:14:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 21:14:16 -0000 Subject: [GHC] #9585: Note about semantics of (!!) is not specific enough, if it's correct In-Reply-To: <045.8790a8448bdb789c8c5b48af4e4acadc@haskell.org> References: <045.8790a8448bdb789c8c5b48af4e4acadc@haskell.org> Message-ID: <060.90025140d677ff90976e7613ec164473@haskell.org> #9585: Note about semantics of (!!) is not specific enough, if it's correct -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"9d713150d87de07e132c1211eec956e0ae69aa7f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9d713150d87de07e132c1211eec956e0ae69aa7f" Remove obsolete comment about (!!) as spotted by David Feuer and reported as #9585. The comment was right until ceb68b9118fa883e88abfaa532fc78f6640cf17f, which is only 13 years ago :-). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 21:23:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 21:23:36 -0000 Subject: [GHC] #9565: T3500b exhaust simplifier ticks (loops?) on WAY=optasm In-Reply-To: <045.21253a4eab836dbd85b1b13d4815a773@haskell.org> References: <045.21253a4eab836dbd85b1b13d4815a773@haskell.org> Message-ID: <060.3d30d63cdb2f861eb2ba1ceb9d9b4864@haskell.org> #9565: T3500b exhaust simplifier ticks (loops?) on WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: T3500b | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): Oh, I see. I propose to mark it as expect_broken for opt targets if noone objects. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 12 23:42:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Sep 2014 23:42:14 -0000 Subject: [GHC] #9565: T3500b exhaust simplifier ticks (loops?) on WAY=optasm In-Reply-To: <045.21253a4eab836dbd85b1b13d4815a773@haskell.org> References: <045.21253a4eab836dbd85b1b13d4815a773@haskell.org> Message-ID: <060.3aa7fbae62ebb85ee9e1e1c4121c92f3@haskell.org> #9565: T3500b exhaust simplifier ticks (loops?) on WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: T3500b | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): I'm not sure, its in the test suite which means it was working before right? Or is this part of the suite that's only run on a slow validate? I'll try to dig in once I'm off my phone. I also may have run the test case incorrectly on my local machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 08:32:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 08:32:57 -0000 Subject: [GHC] #9573: Add warning for invalid digits in integer literals In-Reply-To: <045.6745c955d16114a85008c81a7aea2c4a@haskell.org> References: <045.6745c955d16114a85008c81a7aea2c4a@haskell.org> Message-ID: <060.1e2a5f6cfa705742ba6882a021d6a3ec@haskell.org> #9573: Add warning for invalid digits in integer literals -------------------------------------+------------------------------------- Reporter: vlopez | Owner: vlopez Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Parser) | Keywords: parsing, integer, Resolution: | octal, binary, hexadecimal, Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: | days) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by andreas.abel): I think a parse *error* would be more appropriate (and useful) than a warning. I consider it as a bug rather than a feature that the following parses: {{{ test h = (+)92837492837h }}} Whitespace isn't that expensive anymore, and even cheaper on the black market ;-), so this "feature" does not seem worth preserving. The moral: number literals should have to be terminated by one of the following: whitespace, punctuation (including parenthesis), operators etc, but not just by an alphabetic character. Maybe one can first parse a number literal as it was an identifier (i.e., allow leading numeric characters in identifiers), and then postprocess identifiers that start with a numeric character as number literals, giving parse errors if they do not make sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 11:34:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 11:34:02 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal Message-ID: <042.e53740211d75489f68d7145493cd4f24@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Difficult (2-5 | Type of failure: days) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- More details to follow. I've created this ticket to be able to refer to from related preparatory commits. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 11:38:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 11:38:38 -0000 Subject: [GHC] #9564: Floating point subnormals overrounded on output In-Reply-To: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> References: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> Message-ID: <057.7845c4f678c904b875bf8cc97339017a@haskell.org> #9564: Floating point subnormals overrounded on output -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): For the record, looking through the code, libraries/base/GHC/Float.lhs seems to use {{{FloatToDigits}}} to generate the decimal representation. The algorithm used is "based on" "Printing Floating-Point Numbers Quickly and Accurately"-- by R.G. Burger and R.K. Dybvig in PLDI 96. http://www.cs.indiana.edu/~dyb/pubs /FP-Printing-PLDI96.pdf This version uses a much slower logarithm estimator. It should be improved. In turn, that algorithm was based on "How to Print Floating-Point Numbers Accurately" by Steele and White http://kurtstephens.com/files/p372-steele.pdf but it does not distinguish between significand and insignifican trailing zeros. The latest approach to conversion appears to be "Printing Floating-Point Numbers Quickly and Accurately with Integers" by Florian Loitsch http://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf (Bryan O'Sullivan http://www.serpentine.com/blog/2011/06/29/here-be- dragons-advances-in-problems-you-didnt-even-know-you-had/ has provided a library for the Double version http://hackage.haskell.org/package/double- conversion.) For a full set of references, including to source code, see http://www.ryanjuckett.com/programming/printing-floating-point-numbers/ I'll have a further think about this, including rwbarton's comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 11:50:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 11:50:49 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.75195ed888eb28cb7d87b4183ecbfee1@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: xnyhps Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by xnyhps): * owner: => xnyhps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 12:35:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 12:35:48 -0000 Subject: [GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. Message-ID: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: type family, | Unknown/Multiple ambiguity check | Type of failure: GHC Architecture: Unknown/Multiple | rejects valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Before the type ambiguity check was introduced, I could write the following code {{{ {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} -- {-# LANGUAGE AllowAmbiguousTypes #-} module T where type family Arr (repr :: * -> *) (a :: *) (b :: *) :: * class ESymantics repr where int :: Int -> repr Int add :: repr Int -> repr Int -> repr Int lam :: (repr a -> repr b) -> repr (Arr repr a b) app :: repr (Arr repr a b) -> repr a -> repr b {- te4 :: (Arr repr (Arr repr Int Int) (Arr repr Int Int) ~ Arr repr (Arr repr Int Int) (Arr repr Int b), ESymantics repr) => repr b -} te4 = let c3 = lam (\f -> lam (\x -> f `app` (f `app` (f `app` x)))) in (c3 `app` (lam (\x -> x `add` int 14))) `app` (int 0) -- t = lam (\f -> f `app` int 0) newtype R a = R{unR :: a} type instance Arr R a b = a -> b instance ESymantics R where int = R add (R x) (R y) = R $ x + y lam f = R $ unR . f . R app (R f) (R x) = R $ f x tR = unR te4 }}} (This is a simple code abstracted from a longer code that for sure worked in 2010: I showed it in a SSGIP lecture at Oxford.) The inferred type of te4 is shown in comments. The type is not ideal but the best what can be done under circumstances. In tR, repr is instantiated to R and the type function Arr can finally be applied and the equality constraint resolved. Since then, the type inference has changed and the code no longer type checks: {{{ Could not deduce (Arr repr (Arr repr a0 b0) (Arr repr a2 b0) ~ Arr repr (Arr repr a b) (Arr repr a4 b)) from the context (ESymantics repr, Arr repr a4 a3 ~ Arr repr a b, Arr repr a3 a ~ Arr repr a b) bound by the inferred type for ?c3?: (ESymantics repr, Arr repr a4 a3 ~ Arr repr a b, Arr repr a3 a ~ Arr repr a b) => repr (Arr repr (Arr repr a b) (Arr repr a4 b)) }}} What is worse, there does not appear to be *any* way to get the code to type check. No amount of type annotations helps. The code has to be dramatically re-written, or just given up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 13:27:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 13:27:56 -0000 Subject: [GHC] #9588: Add `MonadPlus {IO, Either e}` and `Alternative (Either e)` instances Message-ID: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> #9588: Add `MonadPlus {IO,Either e}` and `Alternative (Either e)` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following 3 instances are currently Orphans in `transformers` but shall be defined in `base` instead: {{{#!hs instance MonadPlus IO instance MonadPlus (Either e) instance Alterantive (Either e) }}} This proposal by SPJ already passed the CLC back in April and only needs implementing. I'll submit a patch shortly to Phab -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 13:44:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 13:44:52 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.4284a37bc70b8ff91bb0d9842ad92272@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Changes (by hvr): * differential: => Phab:D209 Comment: The medium-sized patch in Phab:D209 implements the **first phase**, namely to re-export solely the two type-classes `Foldable` and `Traversable` (sans any methods) from `Prelude` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 14:07:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 14:07:44 -0000 Subject: [GHC] #9588: Add `MonadPlus {IO, Either e}` and `Alternative (Either e)` instances In-Reply-To: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> References: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> Message-ID: <057.cfb54fbcdb41df81b62b0d1fcb5184d6@haskell.org> #9588: Add `MonadPlus {IO,Either e}` and `Alternative (Either e)` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): I'm hitting a problem while trying to implement this. While the `IO` instances are rather straightforward (and btw, there's also an `Alternative IO` instance defined in `transformers`): {{{#!hs instance MonadPlus IO where mzero = ioError (userError "mzero") m `mplus` n = m `catchIOError` \ _ -> n instance Alternative IO where empty = mzero (<|>) = mplus }}} The instances for `Either`, however, depend on an `Error` class in `transformers` to produce an `empty`/`mzero` value: {{{#!hs instance (Error e) => Alternative (Either e) where empty = Left noMsg Left _ <|> n = n m <|> _ = m instance (Error e) => MonadPlus (Either e) where mzero = Left noMsg Left _ `mplus` n = n m `mplus` _ = m }}} how shall this issue be resolved? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 14:59:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 14:59:50 -0000 Subject: [GHC] #9588: Add `MonadPlus {IO, Either e}` and `Alternative (Either e)` instances In-Reply-To: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> References: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> Message-ID: <057.fc0ed084b30a028d3552ef6c6e4d7409@haskell.org> #9588: Add `MonadPlus {IO,Either e}` and `Alternative (Either e)` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): The `IO` case is easy and should definitely go in. That one is a no- brainer. However, looking at it, I'm rather uncomfortable about the notion of moving the rather ad hoc `Error` class into `base`. Nobody likes it. Perhaps the fate of the `Either` instance should go back out to the libraries mailing list to try to round up ideas. We could a.) Leave it where it is b.) Bring `Error` into base. c.) Switch it to `Monoid`, which is sadly too big and may break some usecases where `noMsg /= mempty` holds now. d.) Bring `Default` into base, which IIRC was already rejected by the `libraries@` list, and use that instead. e.) Figure out something else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 16:43:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 16:43:42 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.6b4d9fc7e0c17bd4afe46dd4007402d5@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"abff2ffd2d6e30b93daa0def282b9fc0795ad10d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="abff2ffd2d6e30b93daa0def282b9fc0795ad10d" Move docstring of `seq` to primops.txt.pp The documentation for `seq` was recently augmented via #9390 & cbfa107604f4cbfaf02bd633c1faa6ecb90c6dd7. However, it doesn't show up in the Haddock generated docs because `#ifdef __HADDOCK__` doesn't work as expected. Also, it's easier to just fix the problem at the origin (which in this is case is the primops.txt.pp file). The benefit/downside of this is that now the extended documentation shows up everywhere `seq` is re-exported directly. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 18:14:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 18:14:42 -0000 Subject: [GHC] #8701: Update libffi-tarballs to latest libffi In-Reply-To: <045.7220d8c135ec272812ad62a34a63cda9@haskell.org> References: <045.7220d8c135ec272812ad62a34a63cda9@haskell.org> Message-ID: <060.13a2c9c644e703f27a39acc9a97e7f94@haskell.org> #8701: Update libffi-tarballs to latest libffi -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1-rc1 (FFI) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"39e206a7badd18792a7c8159cff732c63a9b19e7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="39e206a7badd18792a7c8159cff732c63a9b19e7" Update libffi-tarballs submodule to libffi 3.1 (re #8701) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 21:52:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 21:52:14 -0000 Subject: [GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. In-Reply-To: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> References: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> Message-ID: <058.62eda6bdee0a36f996ced6b950b91d5b@haskell.org> #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: type family, Resolution: | ambiguity check Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Just to be clear, are you saying that `-XAllowAmbiguousTypes` does not suppress the error? (Which it claims to do.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 22:31:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 22:31:40 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.1e9d3626d59254aed995bfd3514a68b9@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): Indeed I was running a precompiled binary that ran out of stack space and gave me this message. Simply rephrasing as "Relink with -rtsopts and use +RTS -Ksize -RTS" would already be nicer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 22:34:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 22:34:05 -0000 Subject: [GHC] #9384: setNumCapabilities call breaks eventlog events In-Reply-To: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> References: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> Message-ID: <060.6dbdffaed31d8780622af61454e45cf5@haskell.org> #9384: setNumCapabilities call breaks eventlog events -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * cc: gintas (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 23:13:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 23:13:15 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.b020379a7a61e707bfeb3cfaf679a126@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): I think I know what's going on here. If you look at parUpsweep in compiler/main/GhcMake.js, its argument n_jobs is used in two places: one is the initial value of the par_sem semaphore used to limit parallelization, and the other is a call to setNumCapabilities. The latter seems to be the cause of the slowdown. Note that setNumCapabilities is only invoked if the previous count of capabilities was 1. I used that to control for both settings independently, and it turns out that the runtime overhead is mostly independent of the semaphore value and highly influenced by capability count. I ran some experiments on a 16-CPU VM (picked a larger one deliberately to make the differences more pronounced). Running with jobs=4 & caps=4, a test took 37s walltime, jobs=4 & caps=16 took 51s, jobs=4 & caps=32 took 114s (344s of MUT and 1021s of GC!). The figures are very similar for jobs=16 and jobs=64. See attached log for more details (-sstderr output). It looks like the runtime GC is just inefficient when running with many capabilities, even if many physical cores are available. I'll try a few experiments to verify that this is a general pattern that is not specific to the GhcMake implementation. Logic and a few experiments indicate that it does not help walltime to set the number of jobs (semaphore value) higher than the number of capabilities, so there's not much we can do about those two parameters in the parUpsweep implementation other than capping n_jobs at some constant (probably <= 8). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 13 23:56:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Sep 2014 23:56:29 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.1594271abe6429d1a43e52718e79a5c7@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): While looking around I found #3758, and it appears that +RTS -qg (disable parallel GC) helps a lot with the superlinear overhead. For example, the benchmark above with jobs=24 & caps=24 without -qg took: real 1m3.596s user 6m31.072s sys 3m10.732s With -qg: real 0m47.747s user 1m33.352s sys 0m2.024s However, for smaller -j values -qg slightly increases walltime: 2 jobs: 44s without -qg, 46s with -qg 4 jobs: 37s vs 40s 8 jobs: 37s vs 41s 15 jobs: 42s vs 44s 16 jobs: 49s vs 44s (walltime crossover point for this 16-core machine) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 00:17:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 00:17:21 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.43a5aaacd4d12e3878a411ca404bcae1@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): Also #8224 looks like it could be related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 00:28:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 00:28:08 -0000 Subject: [GHC] #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' Message-ID: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' -------------------------------------+------------------------------------- Reporter: jpmasseria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Running on Ubuntu 14.04.1 I am trying to build a stage1 cross-compiler for a Raspberry Pi running Raspbian. I am using the tool chain located at https://github.com/raspberrypi/tools. I copied my Raspberry Pi's /include and /usr directories to my build machine into directory `/home/johnma/rpi-toolchain/rootfs`. Following these instructions [https://ghcarm.wordpress.com/2014/01/18 /unregisterised-ghc-head-build-for-arm64-platform/] I force gcc to use my sysroot using this bash script: `/home/johnma/mygcc` contains: {{{ #!/bin/bash arm-linux-gnueabihf-gcc --sysroot=/home/johnma/rpi-toolchain/rootfs $@ }}} I used this configure command: {{{ ./configure --target=arm-linux-gnueabihf --enable-unregisterised --with- gcc=/home/johnma/mygcc --with-nm=/usr/bin/nm }}} The build ends with: {{{ "inplace/bin/ghc-stage1" -o utils/hsc2hs/dist-install/build/tmp/hsc2hs -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist- install/build/autogen -Iutils/hsc2hs/dist-install/build -Iutils/hsc2hs /dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.1 -package containers-0.5.5.1 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist-install/build -hidir utils/hsc2hs/dist-install/build -stubdir utils/hsc2hs/dist- install/build -optl-L'/home/johnma/ghc/libraries/process/dist- install/build' -optl-L'/home/johnma/ghc/libraries/directory/dist- install/build' -optl-L'/home/johnma/ghc/libraries/unix/dist-install/build' -optl-L'/home/johnma/ghc/libraries/time/dist-install/build' -optl-L'/home/johnma/ghc/libraries/old-locale/dist-install/build' -optl-L'/home/johnma/ghc/libraries/filepath/dist-install/build' -optl-L'/home/johnma/ghc/libraries/containers/dist-install/build' -optl-L'/home/johnma/ghc/libraries/bytestring/dist-install/build' -optl-L'/home/johnma/ghc/libraries/deepseq/dist-install/build' -optl-L'/home/johnma/ghc/libraries/array/dist-install/build' -optl-L'/home/johnma/ghc/libraries/base/dist-install/build' -optl-L'/home/johnma/ghc/libraries/integer-simple/dist-install/build' -optl-L'/home/johnma/ghc/libraries/ghc-prim/dist-install/build' -optl-L'/home/johnma/ghc/rts/dist/build' -optl-lrt -optl-lutil -optl- lpthread -optl-lm -optl-lrt -static -H64m -O0 -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist- install/build/autogen -Iutils/hsc2hs/dist-install/build -Iutils/hsc2hs /dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.1 -package containers-0.5.5.1 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts utils/hsc2hs/dist-install/build/Main.o utils/hsc2hs/dist-install/build/HSCParser.o utils/hsc2hs/dist- install/build/DirectCodegen.o utils/hsc2hs/dist- install/build/CrossCodegen.o utils/hsc2hs/dist- install/build/UtilsCodegen.o utils/hsc2hs/dist-install/build/Common.o utils/hsc2hs/dist-install/build/C.o utils/hsc2hs/dist- install/build/Flags.o utils/hsc2hs/dist-install/build/Paths_hsc2hs.o /home/johnma/ghc/rts/dist/build/libHSrts.a(Linker.o): In function `internal_dlopen': Linker.c:(.text+0x68): undefined reference to `dlopen' Linker.c:(.text+0xa4): undefined reference to `dlerror' /home/johnma/ghc/rts/dist/build/libHSrts.a(Linker.o): In function `lookupSymbol': Linker.c:(.text+0x874): undefined reference to `dlerror' Linker.c:(.text+0x89c): undefined reference to `dlsym' Linker.c:(.text+0x8a4): undefined reference to `dlerror' Linker.c:(.text+0x8c4): undefined reference to `dlsym' collect2: error: ld returned 1 exit status make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 00:30:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 00:30:44 -0000 Subject: [GHC] #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' In-Reply-To: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> References: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> Message-ID: <064.3beecdff6662b1eaf4a9ee80676c6418@haskell.org> #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' -------------------------------------+------------------------------------- Reporter: jpmasseria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by jpmasseria: Old description: > Running on Ubuntu 14.04.1 I am trying to build a stage1 cross-compiler > for a Raspberry Pi running Raspbian. I am using the tool chain located > at https://github.com/raspberrypi/tools. > > I copied my Raspberry Pi's /include and /usr directories to my build > machine into directory `/home/johnma/rpi-toolchain/rootfs`. > > Following these instructions [https://ghcarm.wordpress.com/2014/01/18 > /unregisterised-ghc-head-build-for-arm64-platform/] I force gcc to use my > sysroot using this bash script: > > `/home/johnma/mygcc` contains: > {{{ > #!/bin/bash > arm-linux-gnueabihf-gcc --sysroot=/home/johnma/rpi-toolchain/rootfs $@ > }}} > > I used this configure command: > > {{{ > ./configure --target=arm-linux-gnueabihf --enable-unregisterised --with- > gcc=/home/johnma/mygcc --with-nm=/usr/bin/nm > }}} > > > The build ends with: > {{{ > "inplace/bin/ghc-stage1" -o utils/hsc2hs/dist-install/build/tmp/hsc2hs > -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -hide-all-packages -i > -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist- > install/build/autogen -Iutils/hsc2hs/dist-install/build -Iutils/hsc2hs > /dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist- > install/build/autogen/cabal_macros.h -package base-4.7.0.1 -package > containers-0.5.5.1 -package directory-1.2.1.0 -package filepath-1.3.0.2 > -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface > -no-user-package-db -rtsopts -odir utils/hsc2hs/dist-install/build > -hidir utils/hsc2hs/dist-install/build -stubdir utils/hsc2hs/dist- > install/build -optl-L'/home/johnma/ghc/libraries/process/dist- > install/build' -optl-L'/home/johnma/ghc/libraries/directory/dist- > install/build' -optl-L'/home/johnma/ghc/libraries/unix/dist- > install/build' -optl-L'/home/johnma/ghc/libraries/time/dist- > install/build' -optl-L'/home/johnma/ghc/libraries/old-locale/dist- > install/build' -optl-L'/home/johnma/ghc/libraries/filepath/dist- > install/build' -optl-L'/home/johnma/ghc/libraries/containers/dist- > install/build' -optl-L'/home/johnma/ghc/libraries/bytestring/dist- > install/build' -optl-L'/home/johnma/ghc/libraries/deepseq/dist- > install/build' -optl-L'/home/johnma/ghc/libraries/array/dist- > install/build' -optl-L'/home/johnma/ghc/libraries/base/dist- > install/build' -optl-L'/home/johnma/ghc/libraries/integer-simple/dist- > install/build' -optl-L'/home/johnma/ghc/libraries/ghc-prim/dist- > install/build' -optl-L'/home/johnma/ghc/rts/dist/build' -optl-lrt -optl- > lutil -optl-lpthread -optl-lm -optl-lrt -static -H64m -O0 -hide-all- > packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build > -iutils/hsc2hs/dist-install/build/autogen -Iutils/hsc2hs/dist- > install/build -Iutils/hsc2hs/dist-install/build/autogen -optP-include > -optPutils/hsc2hs/dist-install/build/autogen/cabal_macros.h -package > base-4.7.0.1 -package containers-0.5.5.1 -package directory-1.2.1.0 > -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP > -XForeignFunctionInterface -no-user-package-db -rtsopts > utils/hsc2hs/dist-install/build/Main.o utils/hsc2hs/dist- > install/build/HSCParser.o utils/hsc2hs/dist-install/build/DirectCodegen.o > utils/hsc2hs/dist-install/build/CrossCodegen.o utils/hsc2hs/dist- > install/build/UtilsCodegen.o utils/hsc2hs/dist-install/build/Common.o > utils/hsc2hs/dist-install/build/C.o utils/hsc2hs/dist- > install/build/Flags.o utils/hsc2hs/dist-install/build/Paths_hsc2hs.o > /home/johnma/ghc/rts/dist/build/libHSrts.a(Linker.o): In function > `internal_dlopen': > Linker.c:(.text+0x68): undefined reference to `dlopen' > Linker.c:(.text+0xa4): undefined reference to `dlerror' > /home/johnma/ghc/rts/dist/build/libHSrts.a(Linker.o): In function > `lookupSymbol': > Linker.c:(.text+0x874): undefined reference to `dlerror' > Linker.c:(.text+0x89c): undefined reference to `dlsym' > Linker.c:(.text+0x8a4): undefined reference to `dlerror' > Linker.c:(.text+0x8c4): undefined reference to `dlsym' > collect2: error: ld returned 1 exit status > make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make: *** [all] Error 2 > > }}} New description: Running on Ubuntu 14.04.1 I am trying to build a stage1 cross-compiler for a Raspberry Pi running Raspbian. I am using the tool chain located at https://github.com/raspberrypi/tools. I copied my Raspberry Pi's /include and /usr directories to my build machine into directory `/home/johnma/rpi-toolchain/rootfs`. Following these instructions [https://ghcarm.wordpress.com/2014/01/18 /unregisterised-ghc-head-build-for-arm64-platform/] I force gcc to use my sysroot using this bash script: `/home/johnma/mygcc` contains: {{{ #!/bin/bash arm-linux-gnueabihf-gcc --sysroot=/home/johnma/rpi-toolchain/rootfs $@ }}} My `mk/build.mk` file contains: {{{ # Fast build configured for a cross compiler BuildFlavour = quick-cross }}} I used this configure command: {{{ ./configure --target=arm-linux-gnueabihf --enable-unregisterised --with- gcc=/home/johnma/mygcc --with-nm=/usr/bin/nm }}} The build ends with: {{{ "inplace/bin/ghc-stage1" -o utils/hsc2hs/dist-install/build/tmp/hsc2hs -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist- install/build/autogen -Iutils/hsc2hs/dist-install/build -Iutils/hsc2hs /dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.1 -package containers-0.5.5.1 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist-install/build -hidir utils/hsc2hs/dist-install/build -stubdir utils/hsc2hs/dist- install/build -optl-L'/home/johnma/ghc/libraries/process/dist- install/build' -optl-L'/home/johnma/ghc/libraries/directory/dist- install/build' -optl-L'/home/johnma/ghc/libraries/unix/dist-install/build' -optl-L'/home/johnma/ghc/libraries/time/dist-install/build' -optl-L'/home/johnma/ghc/libraries/old-locale/dist-install/build' -optl-L'/home/johnma/ghc/libraries/filepath/dist-install/build' -optl-L'/home/johnma/ghc/libraries/containers/dist-install/build' -optl-L'/home/johnma/ghc/libraries/bytestring/dist-install/build' -optl-L'/home/johnma/ghc/libraries/deepseq/dist-install/build' -optl-L'/home/johnma/ghc/libraries/array/dist-install/build' -optl-L'/home/johnma/ghc/libraries/base/dist-install/build' -optl-L'/home/johnma/ghc/libraries/integer-simple/dist-install/build' -optl-L'/home/johnma/ghc/libraries/ghc-prim/dist-install/build' -optl-L'/home/johnma/ghc/rts/dist/build' -optl-lrt -optl-lutil -optl- lpthread -optl-lm -optl-lrt -static -H64m -O0 -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist- install/build/autogen -Iutils/hsc2hs/dist-install/build -Iutils/hsc2hs /dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.1 -package containers-0.5.5.1 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts utils/hsc2hs/dist-install/build/Main.o utils/hsc2hs/dist-install/build/HSCParser.o utils/hsc2hs/dist- install/build/DirectCodegen.o utils/hsc2hs/dist- install/build/CrossCodegen.o utils/hsc2hs/dist- install/build/UtilsCodegen.o utils/hsc2hs/dist-install/build/Common.o utils/hsc2hs/dist-install/build/C.o utils/hsc2hs/dist- install/build/Flags.o utils/hsc2hs/dist-install/build/Paths_hsc2hs.o /home/johnma/ghc/rts/dist/build/libHSrts.a(Linker.o): In function `internal_dlopen': Linker.c:(.text+0x68): undefined reference to `dlopen' Linker.c:(.text+0xa4): undefined reference to `dlerror' /home/johnma/ghc/rts/dist/build/libHSrts.a(Linker.o): In function `lookupSymbol': Linker.c:(.text+0x874): undefined reference to `dlerror' Linker.c:(.text+0x89c): undefined reference to `dlsym' Linker.c:(.text+0x8a4): undefined reference to `dlerror' Linker.c:(.text+0x8c4): undefined reference to `dlsym' collect2: error: ld returned 1 exit status make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 00:32:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 00:32:23 -0000 Subject: [GHC] #9384: setNumCapabilities call breaks eventlog events In-Reply-To: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> References: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> Message-ID: <060.ee8c78cae57496d891d687eee3db5bba@haskell.org> #9384: setNumCapabilities call breaks eventlog events -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): FWIW I also ran into this bug while trying to profile ghc itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 00:45:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 00:45:02 -0000 Subject: [GHC] #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' In-Reply-To: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> References: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> Message-ID: <064.dc088a4119f0ab0cd055d2d821a0ed41@haskell.org> #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' -------------------------------------+------------------------------------- Reporter: jpmasseria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): From `rts/package.conf.in` {{{ extra-libraries: #ifdef HAVE_LIBM "m" /* for ldexp() */ #endif #ifdef HAVE_LIBRT , "rt" #endif #ifdef HAVE_LIBDL , "dl" #endif ... }}} suggests that `HAVE_LIBDL` is not set for you. What is the output of `inplace/bin/ghc-pkg describe rts`? What does `include/ghcautoconf.h` say about `HAVE_LIBDL`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 04:44:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 04:44:55 -0000 Subject: [GHC] #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' In-Reply-To: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> References: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> Message-ID: <064.0a5943cdab7f81bb9ac300e71c7cd7f1@haskell.org> #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' -------------------------------------+------------------------------------- Reporter: jpmasseria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jpmasseria): `inplace/bin/ghc-pkg describe rts` outputs: {{{ johnma at aspire-ubuntu:~/ghc$ inplace/bin/ghc-pkg describe rts name: rts version: 1.0 id: builtin_rts license: BSD3 copyright: maintainer: glasgow-haskell-users at haskell.org stability: homepage: package-url: synopsis: description: category: author: exposed: True exposed-modules: hidden-modules: trusted: False import-dirs: library-dirs: /home/johnma/ghc/rts/dist/build hs-libraries: HSrts Cffi extra-libraries: m rt extra-ghci-libraries: include-dirs: /home/johnma/ghc/rts/dist/build /home/johnma/ghc/includes /home/johnma/ghc/includes/dist-derivedconstants/header includes: Stg.h depends: hugs-options: cc-options: ld-options: "-Wl,-u,ghczmprim_GHCziTypes_Izh_static_info" "-Wl,-u,ghczmprim_GHCziTypes_Czh_static_info" "-Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info" "-Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info" "-Wl,-u,base_GHCziPtr_Ptr_static_info" "-Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info" "-Wl,-u,base_GHCziInt_I8zh_static_info" "-Wl,-u,base_GHCziInt_I16zh_static_info" "-Wl,-u,base_GHCziInt_I32zh_static_info" "-Wl,-u,base_GHCziInt_I64zh_static_info" "-Wl,-u,base_GHCziWord_W8zh_static_info" "-Wl,-u,base_GHCziWord_W16zh_static_info" "-Wl,-u,base_GHCziWord_W32zh_static_info" "-Wl,-u,base_GHCziWord_W64zh_static_info" "-Wl,-u,base_GHCziStable_StablePtr_static_info" "-Wl,-u,ghczmprim_GHCziTypes_Izh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Czh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info" "-Wl,-u,base_GHCziPtr_Ptr_con_info" "-Wl,-u,base_GHCziPtr_FunPtr_con_info" "-Wl,-u,base_GHCziStable_StablePtr_con_info" "-Wl,-u,ghczmprim_GHCziTypes_False_closure" "-Wl,-u,ghczmprim_GHCziTypes_True_closure" "-Wl,-u,base_GHCziPack_unpackCString_closure" "-Wl,-u,base_GHCziIOziException_stackOverflow_closure" "-Wl,-u,base_GHCziIOziException_heapOverflow_closure" "-Wl,-u,base_ControlziExceptionziBase_nonTermination_closure" "-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure" "-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure" "-Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure" "-Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure" "-Wl,-u,base_GHCziTopHandler_flushStdHandles_closure" "-Wl,-u,base_GHCziTopHandler_runIO_closure" "-Wl,-u,base_GHCziTopHandler_runNonIO_closure" "-Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure" "-Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure" "-Wl,-u,base_GHCziConcziSync_runSparks_closure" "-Wl,-u,base_GHCziConcziSignal_runHandlers_closure" framework-dirs: frameworks: haddock-interfaces: haddock-html: pkgroot: "/home/johnma/ghc/inplace/lib" }}} `includes/ghcautoconf.h` contains: {{{ /* Define to 1 if you need -ldl to get dlopen(). */ /* #undef HAVE_LIBDL */ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 07:41:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 07:41:40 -0000 Subject: [GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. In-Reply-To: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> References: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> Message-ID: <058.102b35e7b704e2077a52068c8dde1393@haskell.org> #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: type family, Resolution: | ambiguity check Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by oleg): Correct: uncommenting the line {-# LANGUAGE AllowAmbiguousTypes #-} does not change the behavior of the type checker for the code in question. And looking at the error message, I didn't think it would. The program is plainly rejected and I don't see what I can possibly do to get it accepted again. I have tried many annotations and small re-writings, to no avail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 10:55:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 10:55:18 -0000 Subject: [GHC] #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' In-Reply-To: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> References: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> Message-ID: <064.d6da3fa3a8f59abf64529797cb4ac074@haskell.org> #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' -------------------------------------+------------------------------------- Reporter: jpmasseria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): What does your config.log say between "checking for dlopen in -ldl" and whatever the next item is (for me it's "checking for size_t")? Is it possible that your toolchain somehow doesn't support dlopen at all? Can you try building a small C program that uses dlopen? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 11:12:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 11:12:27 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.8700258555110cfbad64839b1b8726bb@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9421 | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by cetu86): Inside your cross toolchain there is a directory that is literally called "sysroot". Inside it you'll find your standard unix root. Looks like this {{{ . ??? arm-unknown-linux-gnueabi ??? arm-unknown-linux-gnueabi ??? ??? sysroot ??? ??? bin ??? ??? etc ??? ??? include ??? ??? lib ??? ??? sbin ??? ??? share ??? ??? usr ??? ??? ??? bin ??? ??? ??? include --> ncurses.h, curses.h go here ??? ??? ??? lib --> libncurses.a goes here ??? ??? var }}} If you use ".../sysroot/usr" as prefix everything should go fine. Except ncurses puts its header files in a subdirectory "include/ncurses" but ghc includes the header file as {{{ #include }}} not as {{{ #include }}} What it did was move all files in the ncurses directory one up and create a symlink for compatibility. (in case I'd later install something that expects ncurses in its original place) Like this: {{{ cd sysroot/usr/inlude/ncurses mv * .. cd .. rmdir ncurses ln -s . ncurses }}} Now I have {{{ daniel at inferno:~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux- gnueabi/sysroot/usr/include/ > ls -l ncurs* curs* -rw-r--r-- 1 daniel users 6590 9. Sep 12:38 cursesapp.h -rw-r--r-- 1 daniel users 27646 9. Sep 12:38 cursesf.h -rw-r--r-- 1 daniel users 76252 9. Sep 12:38 curses.h -rw-r--r-- 1 daniel users 19518 9. Sep 12:38 cursesm.h -rw-r--r-- 1 daniel users 8489 9. Sep 12:38 cursesp.h -rw-r--r-- 1 daniel users 49280 9. Sep 12:38 cursesw.h -rw-r--r-- 1 daniel users 7312 9. Sep 12:38 cursslk.h lrwxrwxrwx 1 daniel users 1 9. Sep 14:19 ncurses -> . -rw-r--r-- 1 daniel users 3925 9. Sep 12:38 ncurses_dll.h lrwxrwxrwx 1 daniel users 8 9. Sep 12:38 ncurses.h -> curses.h }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 15:53:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 15:53:46 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.65419d883eba6196c3b5ce7d1b9e55db@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: low | Version: 6.12.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7880 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D211 | -------------------------------------+------------------------------------- Changes (by monoidal): * status: infoneeded => patch * differential: => Phab:D211 Comment: The patch (ghc+haddock) is ready for review in Phabricator, and the change to haskeline was merged. There are only minor changes since the previous patch - I've clarified the documentation and updated TH testcases that were created in the meantime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 16:12:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 16:12:08 -0000 Subject: [GHC] #9356: scanl does not participate in list fusion (was: scanl does not participate in stream fusion) In-Reply-To: <045.ab578058deeca9329303e3b009a823aa@haskell.org> References: <045.ab578058deeca9329303e3b009a823aa@haskell.org> Message-ID: <060.9d4a20b2e08a5673ff435eb2926cbe5b@haskell.org> #9356: scanl does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): It looks like the `concat/inits` issue is probably not a `scanl` issue in principle, and it should be safe enough to merge this patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 16:27:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 16:27:02 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package Message-ID: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: | Version: 7.9 libraries/haskell2010 | Operating System: Keywords: AMP | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (and probably also `haskell98`) I hate to be the one pointing this out, but the AMP has one ugly side- effect. Consider the following session: ``` $ inplace/bin/ghc-stage2 --interactive -XHaskell2010 -hide-all-packages -package haskell2010 GHCi, version 7.9.20140914: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim-0.3.1.0 ... linking ... done. Loading package integer-gmp-0.5.1.0 ... linking ... done. Loading package base-4.8.0.0 ... linking ... done. Loading package array-0.5.0.1 ... linking ... done. Loading package haskell2010-1.1.2.1 ... linking ... done. ?:2> data Identity a = Identity a data Identity a = Identity a ?:3> instance Monad Identity :3:10: No instance for (base-4.8.0.0:GHC.Base.Applicative Identity) arising from the superclasses of an instance declaration In the instance declaration for ?Monad Identity? ?:4> :info Monad class base-4.8.0.0:GHC.Base.Applicative m => Monad (m :: * -> *) where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a -- Defined in ?base-4.8.0.0:GHC.Base? instance Monad (Either e) -- Defined in ?base-4.8.0.0:Data.Either? instance Monad Maybe -- Defined in ?base-4.8.0.0:Data.Maybe? instance Monad [] -- Defined in ?base-4.8.0.0:GHC.Base? instance Monad IO -- Defined in ?base-4.8.0.0:GHC.Base? instance Monad ((->) r) -- Defined in ?base-4.8.0.0:GHC.Base? ?:5> ``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 16:27:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 16:27:27 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.6bee2df432b00ff65aebe9bd17e74755@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: | Version: 7.9 libraries/haskell2010 | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > (and probably also `haskell98`) > > I hate to be the one pointing this out, but the AMP has one ugly side- > effect. > > Consider the following session: > > ``` > $ inplace/bin/ghc-stage2 --interactive -XHaskell2010 -hide-all-packages > -package haskell2010 > GHCi, version 7.9.20140914: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim-0.3.1.0 ... linking ... done. > Loading package integer-gmp-0.5.1.0 ... linking ... done. > Loading package base-4.8.0.0 ... linking ... done. > Loading package array-0.5.0.1 ... linking ... done. > Loading package haskell2010-1.1.2.1 ... linking ... done. > > ?:2> data Identity a = Identity a > data Identity a = Identity a > > ?:3> instance Monad Identity > > :3:10: > No instance for (base-4.8.0.0:GHC.Base.Applicative Identity) arising > from the superclasses of an instance declaration > In the instance declaration for ?Monad Identity? > > ?:4> :info Monad > class base-4.8.0.0:GHC.Base.Applicative m => Monad (m :: * -> *) where > (>>=) :: m a -> (a -> m b) -> m b > (>>) :: m a -> m b -> m b > return :: a -> m a > fail :: String -> m a > -- Defined in ?base-4.8.0.0:GHC.Base? > instance Monad (Either e) -- Defined in ?base-4.8.0.0:Data.Either? > instance Monad Maybe -- Defined in ?base-4.8.0.0:Data.Maybe? > instance Monad [] -- Defined in ?base-4.8.0.0:GHC.Base? > instance Monad IO -- Defined in ?base-4.8.0.0:GHC.Base? > instance Monad ((->) r) -- Defined in ?base-4.8.0.0:GHC.Base? > ?:5> > > ``` New description: (and probably also `haskell98`) I hate to be the one pointing this out, but the AMP has one ugly side- effect. Consider the following session: {{{ $ inplace/bin/ghc-stage2 --interactive -XHaskell2010 -hide-all-packages -package haskell2010 GHCi, version 7.9.20140914: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim-0.3.1.0 ... linking ... done. Loading package integer-gmp-0.5.1.0 ... linking ... done. Loading package base-4.8.0.0 ... linking ... done. Loading package array-0.5.0.1 ... linking ... done. Loading package haskell2010-1.1.2.1 ... linking ... done. ?:2> data Identity a = Identity a data Identity a = Identity a ?:3> instance Monad Identity :3:10: No instance for (base-4.8.0.0:GHC.Base.Applicative Identity) arising from the superclasses of an instance declaration In the instance declaration for ?Monad Identity? ?:4> :info Monad class base-4.8.0.0:GHC.Base.Applicative m => Monad (m :: * -> *) where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a -- Defined in ?base-4.8.0.0:GHC.Base? instance Monad (Either e) -- Defined in ?base-4.8.0.0:Data.Either? instance Monad Maybe -- Defined in ?base-4.8.0.0:Data.Maybe? instance Monad [] -- Defined in ?base-4.8.0.0:GHC.Base? instance Monad IO -- Defined in ?base-4.8.0.0:GHC.Base? instance Monad ((->) r) -- Defined in ?base-4.8.0.0:GHC.Base? ?:5> }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 16:31:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 16:31:30 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.572986c4aa415aa7f69a882dcca7216d@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: | Version: 7.9 libraries/haskell2010 | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: ekmett, thoughtpolice (added) Comment: One obvious way to fix this would be to have `haskell2010` have its own `Monad` typeclass, but this would make it incompatible with `base`'s `Monad`, effectively breaking interoperability between packages depending on `base` and those depending on `haskell2010`... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 18:50:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 18:50:25 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.f2782206f1015497ed69d3b426177c68@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by xnyhps): Yeah, I have Windows and Linux available to test on. Other architectures (PPC/ARM/...) not as easily, so I'll keep the generated code for those unchanged. Gathering up some discussion from GCC about alignment of string literals: * https://gcc.gnu.org/ml/gcc/2002-01/msg01068.html * https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02835.html: {{{ * config/i386/i386.c (ix86_constant_alignment): Decrease alignment of long string literals from 32 bytes to sizeof (void *) when !-Os and to 1 with -Os. }}} * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158 The main argument in favor of alignment seems to be: code often `memcpy`s string literals into buffers. By doing that with aligned addresses (apparently) SSE instructions can be used. This is irrelevant for GHC, because the strings are only parsed into `[Char]`s, never copied. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 19:56:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 19:56:26 -0000 Subject: [GHC] #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' In-Reply-To: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> References: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> Message-ID: <064.c4a5153c8b822d3d726fcbd3691f7094@haskell.org> #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' -------------------------------------+------------------------------------- Reporter: jpmasseria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jpmasseria): Here's what's in my `config.log` related to `-ldl`: {{{ configure:10619: /home/johnma/mygcc -o conftest -g -O2 -fno-stack- protector conftest.c -ldl >&5 /tmp/ccqfJgej.o: In function `main': /home/johnma/ghc/conftest.c:99: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /home/johnma/rpi-toolchain/rootfs/usr/lib/arm-linux- gnueabihf/libdl.a(dlopen.o): In function `dlopen': (.text+0xc): undefined reference to `__dlopen' collect2: error: ld returned 1 exit status configure:10619: $? = 1 }}} This is strange because I am using the tool chain recommended here: [https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 20:59:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 20:59:05 -0000 Subject: [GHC] #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' In-Reply-To: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> References: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> Message-ID: <064.a3f5bfae1a526c8d20c6058ad28aca19@haskell.org> #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' -------------------------------------+------------------------------------- Reporter: jpmasseria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Maybe you are having the same problem as this person: http://stackoverflow.com/questions/13626726/an-error-building-qt- libraries-for-the-raspberry-pi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 21:38:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 21:38:56 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.3a8a7e5dd4278e3c88b0fbbaea0581d2@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 xnyhps]: > The main argument in favor of alignment seems to be: code often `memcpy`s string literals into buffers. By doing that with aligned addresses (apparently) SSE instructions can be used. This is irrelevant for GHC, because the strings are only parsed into `[Char]`s, never copied. Will that always be the case if a string literal represents something like `Text` or `ByteString`? If so, will that continue to hold in the future? Might a future optimization fuse `putStr` with the conversion to do a copy? It may be that these concerns are baseless, but it might make sense to consider what alternative optimizations yours could preclude. You mention that there are a lot of string literals in the Prelude. I would bet that the vast majority of those are error messages. Might it be possible to specifically target ''exceptional'' strings that should never be anywhere speed-critical, and pack them all together? Putting them all together, ideally starting or ending on a page boundary, would (hopefully) mean that they wouldn't even need to be swapped in unless an error occurred. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 14 23:59:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Sep 2014 23:59:07 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.330a7b0de9fd93078339c73d55e108c8@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): Replying to [comment:3 xnyhps]: > The main argument in favor of alignment seems to be: code often `memcpy`s string literals into buffers. By doing that with aligned addresses (apparently) SSE instructions can be used. This is irrelevant for GHC, because the strings are only parsed into `[Char]`s, never copied. We avoid going via `[Char]` when creating `ByteString` literals already today (using RULES). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 03:01:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 03:01:42 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.810470c8fa9bbd0d70cac15e6c1e4988@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: | Version: 7.9 libraries/haskell2010 | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): The fact that the AMP broke strict Haskell2010 compatibility for the `haskell2010` package was a known going in. We already broke it with `Num` a few years ago. We really have two options going forward. We can say that `haskell2010` and `haskell98` and the like are what they are, rough compatibility shims that get you as close as we can to the semantics of those standards without breaking compatibility with other packages... Or we can sink more effort into making them more accurate to their corresponding standards but in the process doom any code that bothers to compile with them to second-class citizen status. I'm rather ambivalent about the choice we make here. So the question comes down to: who is the audience of `haskell2010` the package? Is it educators who want a given standard they can teach to? Folks who have students who mayl eventually cast off the training wheels and move on to write real GHC if they want to build code that fits with the rest of the ecosystem? Or is it users who don't want to let a GHC monoculture set the standard and would prefer to work with a smaller subset of the language, but still want to have access to the ecosystem of packages through cabal? Folks who may have other compilers in mind, who would prefer to implement against a standard or at least have the ability to have their code compile against a compiler that implements the standard. If it is the former, then the story of making haskell2010-specific `Monad` and `Num` classes with their own supplies of instances has some merit. If it is the latter, we'd cripple the ability of that group to work with both packages to make `haskell2010` and `haskell98` export their own version of `Monad` and `Num`. I'm personally inclined to go with the status quo, which is that `haskell2010` is a fairly weak compatibility shim that more directly suits the needs of the second audience, if only because it is the audience who can grow the most, and it takes the least amount of effort investiture on our behalf. If, however, a champion were to stand up and offer to do all the work to maintain a more pedantic `haskell2010` package replete with its own instances for its own `Monad` / `Num`, I wouldn't stand in their way. Frankly, as it stands that could probably be done as an end user project without really involving any input from GHC HQ. If that were done it needn't even conflict with the existing `haskell2010` package. So, with that in mind I'd be content to see the existing package for what it is, and push back the effort to make a better shim on the user who actually wants to confront all the issues involved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 06:38:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 06:38:57 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.d11ebe7f8bc7abbae33e41db29fda5b9@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"c0fa383d9109800a4e46a81b418f1794030ba1bd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c0fa383d9109800a4e46a81b418f1794030ba1bd" Export `Traversable()` and `Foldable()` from Prelude This exposes *only* the type-classes w/o any of their methods. This is the very first step for implementing BPP (see #9586), which already requires breaking up several import-cycles leading back to `Prelude`. Ideally, importing `Prelude` should be avoided in most `base` modules, as `Prelude` does not define any entities, but rather re-exports existing ones. Test Plan: validate passes Reviewers: ekmett, austin Reviewed By: ekmett, austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D209 GHC Trac Issues: #9586 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 06:56:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 06:56:46 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.6450bcda54f1e2366a14a48464428f8c@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: | Version: 7.9 libraries/haskell2010 | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Old description: > (and probably also `haskell98`) > > I hate to be the one pointing this out, but the AMP has one ugly side- > effect. > > Consider the following session: > > {{{ > $ inplace/bin/ghc-stage2 --interactive -XHaskell2010 -hide-all-packages > -package haskell2010 > GHCi, version 7.9.20140914: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim-0.3.1.0 ... linking ... done. > Loading package integer-gmp-0.5.1.0 ... linking ... done. > Loading package base-4.8.0.0 ... linking ... done. > Loading package array-0.5.0.1 ... linking ... done. > Loading package haskell2010-1.1.2.1 ... linking ... done. > > ?:2> data Identity a = Identity a > data Identity a = Identity a > > ?:3> instance Monad Identity > > :3:10: > No instance for (base-4.8.0.0:GHC.Base.Applicative Identity) arising > from the superclasses of an instance declaration > In the instance declaration for ?Monad Identity? > > ?:4> :info Monad > class base-4.8.0.0:GHC.Base.Applicative m => Monad (m :: * -> *) where > (>>=) :: m a -> (a -> m b) -> m b > (>>) :: m a -> m b -> m b > return :: a -> m a > fail :: String -> m a > -- Defined in ?base-4.8.0.0:GHC.Base? > instance Monad (Either e) -- Defined in ?base-4.8.0.0:Data.Either? > instance Monad Maybe -- Defined in ?base-4.8.0.0:Data.Maybe? > instance Monad [] -- Defined in ?base-4.8.0.0:GHC.Base? > instance Monad IO -- Defined in ?base-4.8.0.0:GHC.Base? > instance Monad ((->) r) -- Defined in ?base-4.8.0.0:GHC.Base? > ?:5> > > }}} New description: (and probably also `haskell98`) I hate to be the one pointing this out, but the AMP has one ugly side- effect: As of now, GHC HEAD rejects Haskell2010 programs (which know nothing about the `Applicative` class). Moreover, there's no simple way to access the `Applicative` class in order to write an instance to satisfy non-standard superclass requirement, so it's impossible to define custom `Monad` instances. For instance, consider the following session which worked in GHC 7.6.3 (albeit with an AMP warning): {{{ $ inplace/bin/ghc-stage2 --interactive -XHaskell2010 -hide-all-packages -package haskell2010 GHCi, version 7.9.20140914: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim-0.3.1.0 ... linking ... done. Loading package integer-gmp-0.5.1.0 ... linking ... done. Loading package base-4.8.0.0 ... linking ... done. Loading package array-0.5.0.1 ... linking ... done. Loading package haskell2010-1.1.2.1 ... linking ... done. ?:2> data Identity a = Identity a data Identity a = Identity a ?:3> instance Monad Identity :3:10: No instance for (base-4.8.0.0:GHC.Base.Applicative Identity) arising from the superclasses of an instance declaration In the instance declaration for ?Monad Identity? ?:4> :info Monad class base-4.8.0.0:GHC.Base.Applicative m => Monad (m :: * -> *) where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a -- Defined in ?base-4.8.0.0:GHC.Base? instance Monad (Either e) -- Defined in ?base-4.8.0.0:Data.Either? instance Monad Maybe -- Defined in ?base-4.8.0.0:Data.Maybe? instance Monad [] -- Defined in ?base-4.8.0.0:GHC.Base? instance Monad IO -- Defined in ?base-4.8.0.0:GHC.Base? instance Monad ((->) r) -- Defined in ?base-4.8.0.0:GHC.Base? ?:5> }}} -- Comment (by hvr): (point out the problem in the description more explicitly) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 09:09:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 09:09:50 -0000 Subject: [GHC] #9573: Add warning for invalid digits in integer literals In-Reply-To: <045.6745c955d16114a85008c81a7aea2c4a@haskell.org> References: <045.6745c955d16114a85008c81a7aea2c4a@haskell.org> Message-ID: <060.2233607c208f1ff1b9c1344aa51c1268@haskell.org> #9573: Add warning for invalid digits in integer literals -------------------------------------+------------------------------------- Reporter: vlopez | Owner: vlopez Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Parser) | Keywords: parsing, integer, Resolution: | octal, binary, hexadecimal, Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: | days) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by vlopez): I fully agree with making it an error, and simplifying lexing of numeric literals However, there's at least one test case which would fail.? As for the Haskell report, there's no explicit rule about number literals being separated by whitespace. I'd suggest giving a deprecated warning for 7.10. Then, for 7.12, the lexer can be switched to the new behaviour, and the language report updated accordingly. 1. [http://git.haskell.org/ghc.git/blob/c0fa383d9109800a4e46a81b418f1794030ba1bd:/testsuite/tests/parser/should_run/BinaryLiterals0.hs] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 09:17:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 09:17:29 -0000 Subject: [GHC] #9573: Add warning for invalid digits in integer literals In-Reply-To: <045.6745c955d16114a85008c81a7aea2c4a@haskell.org> References: <045.6745c955d16114a85008c81a7aea2c4a@haskell.org> Message-ID: <060.45e2ea072fb46824f3a089025a0a5944@haskell.org> #9573: Add warning for invalid digits in integer literals -------------------------------------+------------------------------------- Reporter: vlopez | Owner: vlopez Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Parser) | Keywords: parsing, integer, Resolution: | octal, binary, hexadecimal, Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: | days) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:4 vlopez]: > However, there's at least one test case which would fail.? ...damn, I spent quite a bit of time to come up with that test-case to make sure I covered all code-paths and didn't deviate from the octal literal's lexing ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 09:31:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 09:31:24 -0000 Subject: [GHC] #9591: Add custom "Wiki" field in Trac Message-ID: <048.abc646341c4c6a2ec973239fa3b2d045@haskell.org> #9591: Add custom "Wiki" field in Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I want to request a new custom field to Trac called "Wiki page"? Tickets that are about implementing a larger feature have an accompanying wiki page that summarizes the design. It would help my workflow if I could just get to that wiki page from the top of a Trac ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 09:32:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 09:32:29 -0000 Subject: [GHC] #9592: Add link to wiki index in the ticket view on Trac Message-ID: <048.6987748ece46df1b7890c87d4a4593a4@haskell.org> #9592: Add link to wiki index in the ticket view on Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I often want to get from the ticket view to index of all wiki pages. Sadly, ticket view only has links to previous ticket/next ticket in the top right of the page. So to get to the index of wiki pages I need to go to any of the wiki pages in the left panel and only then the link to wiki index appears in the top right of the page. Would it be possible to have link to wiki index also in the ticket view? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 09:32:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 09:32:38 -0000 Subject: [GHC] #9592: Add link to wiki index in the ticket view on Trac In-Reply-To: <048.6987748ece46df1b7890c87d4a4593a4@haskell.org> References: <048.6987748ece46df1b7890c87d4a4593a4@haskell.org> Message-ID: <063.5de37a5ba78e3cb5b9fe8c0d4cd401cd@haskell.org> #9592: Add link to wiki index in the ticket view on Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: hvr Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Trac & Git | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * version: 7.8.2 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 10:11:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 10:11:29 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.314da6ac01370946531d43ff17707d43@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): > what's wrong with exponential time here? Compilation times. If a type family takes a single argument then obviously there is only one possible injectivity condition ("result -> a"). For two arguments there are 5 possible injectivity conditions. For 3 this number jumps to 19. 4 arguments => 65 combinations. 5 arguments => 211 combinations. 6 arguments => 665 combinations. Let's assume (for illustrative purposes) that verifying (ie. attempting to infer) a single injectivity condition for a type family takes 0.01s. Under such assumptions inferring all possible injectivity conditions for a type family with 6 arguments will take ~6.5s. We can't do that. > Is there any patch which would allow me to use injective type families in current GHC? No. But if all goes well all this discussion here will culminate with such a patch :-) In the meantime, if you have any motivating use cases that require injectivity to work please share them if you can. This would be most helpful. I've spent last several days thinking intensely about the design and made some progress. Hopefully, I'll incorporate my notes into the wiki page by the end of the week. Will get back with some ideas and proposals once this happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 12:15:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 12:15:27 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.9245461dbd3c46a5a3b491617a0f4ec2@haskell.org> #7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: jstolarek AlessandroVermeulen | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #1537, #3613 Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D72 | -------------------------------------+------------------------------------- Comment (by simonpj): See also [http://blog.spacekitteh.moe/posts/new-monoidal-cats.html Sophie Taylor's proposal] about monoidal category classes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 12:40:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 12:40:58 -0000 Subject: [GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. In-Reply-To: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> References: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> Message-ID: <058.39a6c7830f50b23b985dec396567caaa@haskell.org> #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: type family, Resolution: | ambiguity check Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I've tried this with GHC 7.6 and 7.4 as well as 7.8.3. When compiling the code you give above, all of them say {{{ T9587.hs:26:11: Could not deduce (Arr repr (Arr repr a4 a3) (Arr repr a4 b) ~ Arr repr (Arr repr a2 a1) (Arr repr a2 b0)) from the context (ESymantics repr, Arr repr a3 a ~ Arr repr a4 a3, Arr repr a b ~ Arr repr a4 a3) bound by the inferred type for `c3': (ESymantics repr, Arr repr a3 a ~ Arr repr a4 a3, Arr repr a b ~ Arr repr a4 a3) => repr (Arr repr (Arr repr a4 a3) (Arr repr a4 b)) at T9587.hs:26:11-68 NB: `Arr' is a type function, and may not be injective Expected type: repr (Arr repr (Arr repr a3 a) (Arr repr a3 b)) Actual type: repr (Arr repr (Arr repr a2 a1) (Arr repr a2 b0)) When checking that `c3' has the inferred type `forall (repr1 :: * -> *) b1 a4 a5 a6. (ESymantics repr1, Arr repr1 a5 a4 ~ Arr repr1 a6 a5, Arr repr1 a4 b1 ~ Arr repr1 a6 a5) => repr1 (Arr repr1 (Arr repr1 a6 a5) (Arr repr1 a6 b1))' Probable cause: the inferred type is ambiguous In the expression: let c3 = lam (\ f -> lam (\ x -> ...)) in (c3 `app` (lam (\ x -> x `add` int 14))) `app` (int 0) }}} So are you saying that something has changed? If so, what? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 13:02:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 13:02:30 -0000 Subject: [GHC] #3658: Dynamically link GHCi (and use system linker) on platforms that support it In-Reply-To: <047.129d39e2608fc274aa7ba90c094c6a82@haskell.org> References: <047.129d39e2608fc274aa7ba90c094c6a82@haskell.org> Message-ID: <062.493523b3380ade86f1fffc3ae3b4aba3@haskell.org> #3658: Dynamically link GHCi (and use system linker) on platforms that support it -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: task | Status: closed Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 6.10.4 Resolution: fixed | Keywords: dynamic link Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 1883, | 3242, 3372, 3654, 4244, 5062, | 5197, 6107, 7072, 7103, 7316, | 7389, 7475, 7687 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * blockedby: 5987 => Comment: I'm going to close this out of the rationale that #5987 is really a regression: dynamically linked GHC should work on Windows, but currently doesn't. Nonetheless, we do link on platforms where we support it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 15:32:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 15:32:55 -0000 Subject: [GHC] #8752: System.FilePath.Windows.combine does not really check isAbsolute In-Reply-To: <047.ba20b266365045acfd96ace488f847bb@haskell.org> References: <047.ba20b266365045acfd96ace488f847bb@haskell.org> Message-ID: <062.1a71c0ddf9bdfc55237a504a4475e68c@haskell.org> #8752: System.FilePath.Windows.combine does not really check isAbsolute -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.9 (other) | Keywords: filepath Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie * version: 7.6.3 => 7.9 Comment: Are you proposing a change to the behavior of `combine`, or can we just change its docstring to: "Combine two paths, if the second path 'isAbsolute' or starts with a path separator, then it returns the second." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 16:15:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 16:15:01 -0000 Subject: [GHC] #8752: System.FilePath.Windows.combine does not really check isAbsolute In-Reply-To: <047.ba20b266365045acfd96ace488f847bb@haskell.org> References: <047.ba20b266365045acfd96ace488f847bb@haskell.org> Message-ID: <062.49f6b4a20b3a673a12969fa797d389c0@haskell.org> #8752: System.FilePath.Windows.combine does not really check isAbsolute -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.9 (other) | Keywords: filepath Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by joeyhess): Changing the doc string in only System.FilePath.Windows.combine would be confusing because System.FilePath.Posix.combine has the same doc string. And I assume most users just use System.FilePath and assume it works for any OS, so probably won't notice if the windows version has a caveat added. Would changing the implementation to really check isAbsolute be likely to break things? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 16:26:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 16:26:10 -0000 Subject: [GHC] #9593: Edit New issue Building current ghc HEAD fails with globalRegMaybe not defined for this platform Message-ID: <047.b513f6d5b7f08c66f27c72ad328610e0@haskell.org> #9593: Edit New issue Building current ghc HEAD fails with globalRegMaybe not defined for this platform -------------------------------------+------------------------------------- Reporter: angerman | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (LLVM) | Version: 7.9 Keywords: | Operating System: MacOS X Architecture: arm | Type of failure: Building Difficulty: Easy (less than 1 | GHC failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140906 for arm-apple-ios): globalRegMaybe not defined for this platform Patch is at https://phabricator.haskell.org/D208 already. A similar bug for non-registers builds was raised as #9055 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 16:26:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 16:26:45 -0000 Subject: [GHC] #9593: Edit New issue Building current ghc HEAD fails with globalRegMaybe not defined for this platform In-Reply-To: <047.b513f6d5b7f08c66f27c72ad328610e0@haskell.org> References: <047.b513f6d5b7f08c66f27c72ad328610e0@haskell.org> Message-ID: <062.3185258d942d4be72ae40c240c56e4f2@haskell.org> #9593: Edit New issue Building current ghc HEAD fails with globalRegMaybe not defined for this platform -------------------------------------+------------------------------------- Reporter: angerman | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (LLVM) | Keywords: Resolution: | Architecture: arm Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by angerman: Old description: > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 7.9.20140906 for arm-apple-ios): > globalRegMaybe not defined for this platform > > Patch is at https://phabricator.haskell.org/D208 already. > > A similar bug for non-registers builds was raised as #9055 New description: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140906 for arm-apple-ios): globalRegMaybe not defined for this platform }}} Patch is at https://phabricator.haskell.org/D208 already. A similar bug for non-registers builds was raised as #9055 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 16:46:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 16:46:05 -0000 Subject: [GHC] #9593: Edit New issue Building current ghc HEAD fails with globalRegMaybe not defined for this platform In-Reply-To: <047.b513f6d5b7f08c66f27c72ad328610e0@haskell.org> References: <047.b513f6d5b7f08c66f27c72ad328610e0@haskell.org> Message-ID: <062.373ebdb9228b2071fe4575e19f50cfba@haskell.org> #9593: Edit New issue Building current ghc HEAD fails with globalRegMaybe not defined for this platform -------------------------------------+------------------------------------- Reporter: angerman | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (LLVM) | Keywords: Resolution: | Architecture: arm Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D208 | -------------------------------------+------------------------------------- Changes (by adamse): * differential: => Phab:D208 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 17:25:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 17:25:30 -0000 Subject: [GHC] #8752: System.FilePath.Windows.combine does not really check isAbsolute In-Reply-To: <047.ba20b266365045acfd96ace488f847bb@haskell.org> References: <047.ba20b266365045acfd96ace488f847bb@haskell.org> Message-ID: <062.4475fc1db4f9455047878d8a2a2875e1@haskell.org> #8752: System.FilePath.Windows.combine does not really check isAbsolute -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.9 (other) | Keywords: filepath Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Can you explain why the docstring I posed is confusing? It is valid for both Posix as Windows, so it's not really a caveat. Correct me if I'm wrong, but the way I understand it is that on [http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247.aspx Windows], if a filepath starts with a single slash, it is considered to be relative to the root of the current drive. The system keeps track of the current drive along with the current directory of that drive. Currently, if the second argument starts with a slash, `combine` returns it as is. The implementation is essentially: {{{ combine a b | hasDrive b || hasLeadingPathSeparator b = b | otherwise = combineAlways a b }}} I am guessing you are looking for the following behavior: {{{ combine "C:\\" "\\foo\\bar" == "C:\\foo\\bar" combine "C:\\STUFF" "\\foo\\bar" == "C:\\foo\\bar" combine ""\\\\shared" "\\foo\\bar" == "\\\\shared\\foo\\bar" combine ""\\\\shared\\stuff" "\\foo\\bar" == "\\\\shared\\foo\\bar" }}} But, since anything else doesn't make any sense: {{{ combine "home" "/bob" == "/bob" }}} So just changing the check to `isAbsolute` (or `hasDrive`, since combining with "C:foo", which isRelative, is not implemented at the moment, but that is another issue) doesn't work. An implementation that has this behavior would be: {{{ combine a b | hasDrive b || hasLeadingPathSeparator b && not (hasDrive a) = b | hasLeadingPathSeparator b = combineAlways (takeDrive a) (dropLeadingPathSeparator b) | otherwise = combineAlways a b }}} Or, an option with the same behavior as above, except: {{{ combine "C:\\STUFF" "\\foo\\bar" == "\\foo\\bar" combine ""\\\\shared\\stuff" "\\foo\\bar" == "\\foo\\bar" }}} , would be: {{{ combine a b | hasDrive b || hasLeadingPathSeparator b && not (isDrive a) = b | hasLeadingPathSeparator b = combineAlways a (dropLeadingPathSeparator b) | otherwise = combineAlways a b }}} I'm not sure which of the three is better. We have to change the docstring either way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 18:04:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 18:04:14 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.8c8aec39bb8e80c259a10246d21c5a74@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by danilo2): @jstolarek: Yes, I've got an example here - by the way, I would be very thankful if you look at it, because I'm scratching my head against it for over two days now and cannot solve it in any way. But this problem is very specific one - you can read detailed description and solutions attemps here: http://stackoverflow.com/questions/25854072/injective-type-families- in-haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 18:22:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 18:22:34 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.e46c5ab32a32f085e870581b7c0df81d@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1241, #2247, None/Unknown | #8356, #9103, #9227 Test Case: | Blocking: | Differential Revisions: Phab:D69 | -------------------------------------+------------------------------------- Comment (by danilo2): Goldfire - I would do it as fast as possible. But first I have to solve an issue I've got here at the company I'm working at. It is connected to injective type families (if I'm not wrong). Anyway it shows, that we cannot do something in Haskell, which should be doable in my opinion. I would be very thankful if you Goldfire or Simon just look at it and give maybe any hints how can we solve it: http://stackoverflow.com/questions/25854072/injective-type-families-in- haskell After solving it I will start working on the tests asap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 18:28:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 18:28:51 -0000 Subject: [GHC] #9594: Cleanup of filepath package Message-ID: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> #9594: Cleanup of filepath package -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.9 Keywords: filepath | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #8752 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I did a general cleanup/refactoring of the filepath package. Notable changes: * 10% less code * 2 tiny bug fixes * a few extra tests * some more documentation The commits are in my [https://github.com/thomie/filepath/commits/cleanup cleanup branch] on Github. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 18:29:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 18:29:17 -0000 Subject: [GHC] #9594: Cleanup of filepath package In-Reply-To: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> References: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> Message-ID: <060.971f01a56f6ef44730cd14ffd72dcb78@haskell.org> #9594: Cleanup of filepath package -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: libraries | Version: 7.9 (other) | Keywords: filepath Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8752 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 18:47:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 18:47:45 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.455a400424ca73fe8bcd0538416937d9@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1241, #2247, None/Unknown | #8356, #9103, #9227 Test Case: | Blocking: | Differential Revisions: Phab:D69 | -------------------------------------+------------------------------------- Comment (by goldfire): I've responded to that !StackOverflow post. (By the way, my name is Richard Eisenberg -- I have no intent on hiding my identity behind the name "goldfire".) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 19:06:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 19:06:40 -0000 Subject: [GHC] #9595: GHCi tab autocomplete include invisible modules Message-ID: <045.39cf414ab4b169eaf14af57d6d01d63b@haskell.org> #9595: GHCi tab autocomplete include invisible modules -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Reported to me by hvr. It was broken in the refactoring of the package code. We need a test for this. Long term, we need to do something more reasonable when there are duplicate modules, since autocomplete will suggest the name, but we can't actually handle it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 19:10:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 19:10:51 -0000 Subject: [GHC] #9554: Pathological type family turns type error into runtime loop In-Reply-To: <047.10c0d6cec996432d07767233097ef363@haskell.org> References: <047.10c0d6cec996432d07767233097ef363@haskell.org> Message-ID: <062.9e1492915b1fe23c69d0d2dee975c1c3@haskell.org> #9554: Pathological type family turns type error into runtime loop -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 19:45:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 19:45:32 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.c7094edeb2d685f0ad9174fd37b052a5@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): Any progress? I ran into this while messing around with a Windows build of GHC on msys2, which uses pacman, where python3 is the default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 20:16:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 20:16:05 -0000 Subject: [GHC] #9595: GHCi tab autocomplete include invisible modules In-Reply-To: <045.39cf414ab4b169eaf14af57d6d01d63b@haskell.org> References: <045.39cf414ab4b169eaf14af57d6d01d63b@haskell.org> Message-ID: <060.75e35bc289bf4455d2590f93d504e921@haskell.org> #9595: GHCi tab autocomplete include invisible modules -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: {{{ commit b72478f41b85337b84edab8f625d103e197f116c Author: Edward Z. Yang Date: Mon Sep 15 13:14:30 2014 -0700 Don't offer hidden modules for autocomplete. It was annoying to test GHCi directly, so I added a ghc-api unit test of the function instead. Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 20:16:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 20:16:12 -0000 Subject: [GHC] #9101: Build 7.8.2 from sources on Windows/msys2 In-Reply-To: <047.9aaf79de73007bb10bd989466d9c86e1@haskell.org> References: <047.9aaf79de73007bb10bd989466d9c86e1@haskell.org> Message-ID: <062.c27397832a1a5a1d5e012092a5534993@haskell.org> #9101: Build 7.8.2 from sources on Windows/msys2 -------------------------------------+------------------------------------- Reporter: cchantep | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * cc: gintas (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 20:25:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 20:25:26 -0000 Subject: [GHC] #9594: Cleanup of filepath package In-Reply-To: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> References: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> Message-ID: <060.c50327caa059c0bb55a86aaf8b3ac7e3@haskell.org> #9594: Cleanup of filepath package -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: libraries | Version: 7.9 (other) | Keywords: filepath Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8752 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): please feel free to submit that as a pull-request to the `haskell/filepath` (even though it says "dont use yet") so we can start code-reviewing :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 15 22:16:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Sep 2014 22:16:24 -0000 Subject: [GHC] #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' In-Reply-To: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> References: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> Message-ID: <064.28889c292e0fb957fd80582cb5224844@haskell.org> #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' -------------------------------------+------------------------------------- Reporter: jpmasseria | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jpmasseria): * status: new => infoneeded Comment: Thank you for your assistance. Looking at the contents of a copy of `/lib` and `/usr/lib` from my target machine (RaspberryPi) it appears that I may not have `libc6-dev` installed on that machine. Unfortunately I am unable to access my target machine remotely and won't be able to perform a `dpkg -l` on it until the weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 03:43:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 03:43:38 -0000 Subject: [GHC] #9596: Create monoidal category framework for arrow desugarer Message-ID: <050.5943b671786c1c07283b6317d06d031c@haskell.org> #9596: Create monoidal category framework for arrow desugarer -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: task | spacekitteh Priority: normal | Status: new Component: GHC API | Milestone: 7.10.1 Keywords: | Version: Architecture: Unknown/Multiple | Operating System: Difficulty: Project (more | Unknown/Multiple than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm going to put it into a GHC namespace (GHC.Arrows.Experimental, perhaps) and put instances for Arrow and such in there as well. In a later ticket I'll work on the desugarer, converting erverything into SMC combinators rather than Arrow combinators. The basic design is [blog.spacekitteh.moe/posts/new-monoidal-cats.html here] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 03:43:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 03:43:48 -0000 Subject: [GHC] #9596: Create monoidal category framework for arrow desugarer In-Reply-To: <050.5943b671786c1c07283b6317d06d031c@haskell.org> References: <050.5943b671786c1c07283b6317d06d031c@haskell.org> Message-ID: <065.2820a448ddaac20cafa0b3ff32b67822@haskell.org> #9596: Create monoidal category framework for arrow desugarer -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh spacekitteh | Status: new Type: task | Milestone: 7.10.1 Priority: normal | Version: Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by spacekitteh: Old description: > I'm going to put it into a GHC namespace (GHC.Arrows.Experimental, > perhaps) and put instances for Arrow and such in there as well. In a > later ticket I'll work on the desugarer, converting erverything into SMC > combinators rather than Arrow combinators. > > The basic design is [blog.spacekitteh.moe/posts/new-monoidal-cats.html > here] New description: I'm going to put it into a GHC namespace (GHC.Arrows.Experimental, perhaps) and put instances for Arrow and such in there as well. In a later ticket I'll work on the desugarer, converting erverything into SMC combinators rather than Arrow combinators. The basic design is [http://blog.spacekitteh.moe/posts/new-monoidal- cats.html here] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 04:04:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 04:04:26 -0000 Subject: [GHC] #9596: Create monoidal category framework for arrow desugarer In-Reply-To: <050.5943b671786c1c07283b6317d06d031c@haskell.org> References: <050.5943b671786c1c07283b6317d06d031c@haskell.org> Message-ID: <065.00a1e281f0800049ba04e1fd4f361fca@haskell.org> #9596: Create monoidal category framework for arrow desugarer -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh spacekitteh | Status: new Type: task | Milestone: 7.10.1 Priority: normal | Version: Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: 7828 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by spacekitteh): * related: => 7828 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 04:04:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 04:04:35 -0000 Subject: [GHC] #9596: Create monoidal category framework for arrow desugarer In-Reply-To: <050.5943b671786c1c07283b6317d06d031c@haskell.org> References: <050.5943b671786c1c07283b6317d06d031c@haskell.org> Message-ID: <065.41ade55f55699e85d1e267c21d94e05c@haskell.org> #9596: Create monoidal category framework for arrow desugarer -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh spacekitteh | Status: new Type: task | Milestone: 7.10.1 Priority: normal | Version: Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: #7828 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by spacekitteh): * related: 7828 => #7828 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 05:16:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 05:16:54 -0000 Subject: [GHC] #9596: Create monoidal category framework for arrow desugarer In-Reply-To: <050.5943b671786c1c07283b6317d06d031c@haskell.org> References: <050.5943b671786c1c07283b6317d06d031c@haskell.org> Message-ID: <065.7f71279b9a6290a99400032565657028@haskell.org> #9596: Create monoidal category framework for arrow desugarer -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh spacekitteh | Status: new Type: task | Milestone: 7.10.1 Priority: normal | Version: Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: #7828 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by spacekitteh: Old description: > I'm going to put it into a GHC namespace (GHC.Arrows.Experimental, > perhaps) and put instances for Arrow and such in there as well. In a > later ticket I'll work on the desugarer, converting erverything into SMC > combinators rather than Arrow combinators. > > The basic design is [http://blog.spacekitteh.moe/posts/new-monoidal- > cats.html here] New description: I'm going to put it into a GHC namespace (GHC.Arrows.Experimental, perhaps) and put instances for Arrow and such in there as well. In a later ticket I'll work on the desugarer, converting erverything into SMC combinators rather than Arrow combinators. The basic design is [http://blog.spacekitteh.moe/posts/new-monoidal- cats.html here]. The current Arrow story is such a mess that makes it nearly unusable. Hopefully, by breaking it apart and making it more general, it will result in clearer code in both GHC and end-user code. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 06:45:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 06:45:42 -0000 Subject: [GHC] #8010: Add forkOSUnmasked (patch) In-Reply-To: <048.eb7119d903e5adba0673b07e7cf0b9ea@haskell.org> References: <048.eb7119d903e5adba0673b07e7cf0b9ea@haskell.org> Message-ID: <063.3b86f5b6b626d92d3cfc02ac684c50d1@haskell.org> #8010: Add forkOSUnmasked (patch) -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Proposal has passed with a little support and no resistance, so I guess we're good to go? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 07:23:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 07:23:10 -0000 Subject: [GHC] #9597: config.guess too old to detect system type under msys2 Message-ID: <045.3368d344e8d197a5bda3e38d698220e3@haskell.org> #9597: config.guess too old to detect system type under msys2 -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The version of config.guess in the GHC repository is too old to correctly detect the system type when running under msys2, which causes ./configure to fail. The attached patch updates config.guess to the latest version which deals with msys2 correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 07:24:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 07:24:03 -0000 Subject: [GHC] #9597: config.guess too old to detect system type under msys2 In-Reply-To: <045.3368d344e8d197a5bda3e38d698220e3@haskell.org> References: <045.3368d344e8d197a5bda3e38d698220e3@haskell.org> Message-ID: <060.848a255bc84ace61b3fc6b500898c742@haskell.org> #9597: config.guess too old to detect system type under msys2 -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 07:26:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 07:26:47 -0000 Subject: [GHC] #9598: GHC fails to build on Windows because of AMB breakage in haskeline Message-ID: <045.fbaf99a5052a962384a061b49eddf557@haskell.org> #9598: GHC fails to build on Windows because of AMB breakage in haskeline -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 07:28:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 07:28:11 -0000 Subject: [GHC] #9598: GHC fails to build on Windows because of AMB breakage in haskeline In-Reply-To: <045.fbaf99a5052a962384a061b49eddf557@haskell.org> References: <045.fbaf99a5052a962384a061b49eddf557@haskell.org> Message-ID: <060.d29d46ec3f8b2b43be4538cc1891e8aa@haskell.org> #9598: GHC fails to build on Windows because of AMB breakage in haskeline -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: high | Milestone: Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => patch * cc: ekmett (added) * component: Compiler => Core Libraries * priority: normal => high * failure: None/Unknown => Building GHC failed * version: 7.8.2 => 7.9 * os: Unknown/Multiple => Windows Comment: See attached patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 07:37:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 07:37:41 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.eb679aebf177b1d345443e8771079859@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by xnyhps): Replying to [comment:4 dfeuer]: > Replying to [comment:3 xnyhps]: > > The main argument in favor of alignment seems to be: code often `memcpy`s string literals into buffers. By doing that with aligned addresses (apparently) SSE instructions can be used. This is irrelevant for GHC, because the strings are only parsed into `[Char]`s, never copied. > > Will that always be the case if a string literal represents something like `Text` or `ByteString`? If so, will that continue to hold in the future? Might a future optimization fuse `putStr` with the conversion to do a copy? It may be that these concerns are baseless, but it might make sense to consider what alternative optimizations yours could preclude. For the record, this is the rewrite rule used by ByteString: * https://github.com/haskell/bytestring/blob/master/Data/ByteString/Internal.hs#L250, calling https://github.com/haskell/bytestring/blob/master/Data/ByteString/Internal.hs#L271. This just wraps the `Addr#` directly, no copying here. However, [https://github.com/haskell/bytestring/blob/master/Data/ByteString/Internal.hs#L522 append] does call `memcpy` twice. I don't think GHC has the kind of optimizations that can turn a `memcpy` call into SIMD instructions directly, but maybe `memcpy` is more efficient when called with aligned buffers. I'll try to test this. And these are the rewrite rules for text: * https://github.com/bos/text/blob/e33c89be4256fdd1c31f39d8a2a63e58e23b0182/Data/Text.hs#L409 calling https://github.com/bos/text/blob/e33c89be4256fdd1c31f39d8a2a63e58e23b0182/Data/Text/Internal/Fusion/Common.hs#L144 A loop similar to `unpackCString#`, so alignment won't matter much. It is true that we might find optimizations later that benefit from aligned strings. But unaligning them now doesn't preclude that. Literals only exist within a single module, so any optimization has control over both the literal and the code that uses it. (`Strings` can be exported, but `Addr#`s can't.) Even if someone would try to mix object files generated by different versions of GHC it wouldn't be a problem. > You mention that there are a lot of string literals in the Prelude. I would bet that the vast majority of those are error messages. Might it be possible to specifically target ''exceptional'' strings that should never be anywhere speed-critical, and pack them all together? Putting them all together, ideally starting or ending on a page boundary, would (hopefully) mean that they wouldn't even need to be swapped in unless an error occurred. I'm not familiar enough with assembly or executable file formats to say whether this is possible, but I'll keep it in mind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 09:12:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 09:12:33 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.1bc47a7e30b64efafaa958befad5ebee@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): Replying to [comment:6 xnyhps]: > For the record, this is the rewrite rule used by ByteString: > > * https://github.com/haskell/bytestring/blob/master/Data/ByteString/Internal.hs#L250, calling https://github.com/haskell/bytestring/blob/master/Data/ByteString/Internal.hs#L271. > > This just wraps the `Addr#` directly, no copying here. However, [https://github.com/haskell/bytestring/blob/master/Data/ByteString/Internal.hs#L522 append] does call `memcpy` twice. I don't think GHC has the kind of optimizations that can turn a `memcpy` call into SIMD instructions directly, but maybe `memcpy` is more efficient when called with aligned buffers. I'll try to test this. The memcpy implementation (used by e.g. `copyByteArray#`) does unroll memcpys of statically known size and alignment, if aligned to a word, so I definitely think we should try to align our data that way. In 7.10 (if Phab:D166 goes in) we'll do even better and use a `REP-MOVSB` instruction on Ivy bridge and newer. `REP-MOVSB` is almost as fast as an unrolled AVX loop. The memcpy unrolling is implemented in source:compiler/nativeGen/X86/CodeGen.hs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 09:16:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 09:16:40 -0000 Subject: [GHC] #9598: GHC fails to build on Windows because of AMP breakage in haskeline (was: GHC fails to build on Windows because of AMB breakage in haskeline) In-Reply-To: <045.fbaf99a5052a962384a061b49eddf557@haskell.org> References: <045.fbaf99a5052a962384a061b49eddf557@haskell.org> Message-ID: <060.1188c765ac13869e1411f36386a07f36@haskell.org> #9598: GHC fails to build on Windows because of AMP breakage in haskeline -------------------------------------+------------------------------------- Reporter: gintas | Owner: thoughtpolice Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: libraries | Version: 7.9 (other) | Keywords: haskeline Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => haskeline * owner: => thoughtpolice * component: Core Libraries => libraries (other) * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 09:53:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 09:53:21 -0000 Subject: [GHC] #9597: config.guess too old to detect system type under msys2 In-Reply-To: <045.3368d344e8d197a5bda3e38d698220e3@haskell.org> References: <045.3368d344e8d197a5bda3e38d698220e3@haskell.org> Message-ID: <060.f9596c5af6c80631f5585ebdad17bdee@haskell.org> #9597: config.guess too old to detect system type under msys2 -------------------------------------+------------------------------------- Reporter: gintas | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: => hvr Comment: I was planning to update all `config.{guess,sub}` files soon anyway (I hit the very same issue you encountered a few weeks ago, but thought I was using the wrong msys2 `.bat` file) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 10:19:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 10:19:50 -0000 Subject: [GHC] #9597: config.guess too old to detect system type under msys2 In-Reply-To: <045.3368d344e8d197a5bda3e38d698220e3@haskell.org> References: <045.3368d344e8d197a5bda3e38d698220e3@haskell.org> Message-ID: <060.0b68bc02d209db16c2b2f663f4f49dce@haskell.org> #9597: config.guess too old to detect system type under msys2 -------------------------------------+------------------------------------- Reporter: gintas | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"72d6d0c2704ee6d984df45f7393c399c0f62a9a9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="72d6d0c2704ee6d984df45f7393c399c0f62a9a9" Update config.{guess,sub} to GNU automake 1.14.1 The new versions should work better under MSYS2 A few submodules' `config.{guess,sub}` files were updated as well With this commit, all config.{guess,sub} files in the GHC tree have the md5sums 0fb81517303511f05a01b14f41cec2cf config.guess d2a165dceaa5ac1edba3c512f6ca7bd1 config.sub This addresses #9597 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 10:22:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 10:22:12 -0000 Subject: [GHC] #9597: config.guess too old to detect system type under msys2 In-Reply-To: <045.3368d344e8d197a5bda3e38d698220e3@haskell.org> References: <045.3368d344e8d197a5bda3e38d698220e3@haskell.org> Message-ID: <060.8dd36264d54cca95c2df3bcd0ee1b275@haskell.org> #9597: config.guess too old to detect system type under msys2 -------------------------------------+------------------------------------- Reporter: gintas | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed Comment: (see also d24a618e4c1d78e5b8684e61d6518711f4e6408e) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 12:46:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 12:46:47 -0000 Subject: [GHC] #9596: Create monoidal category framework for arrow desugarer In-Reply-To: <050.5943b671786c1c07283b6317d06d031c@haskell.org> References: <050.5943b671786c1c07283b6317d06d031c@haskell.org> Message-ID: <065.049d59b03c58b4872194ea6ce1b30649@haskell.org> #9596: Create monoidal category framework for arrow desugarer -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh spacekitteh | Status: new Type: task | Milestone: 7.10.1 Priority: normal | Version: Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: #7828 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I urge you to document your design on a GHC Trac wiki page, including writing out all the typing and desugaring rules, before staring work on an implementation. No sense in implementing something only to realise the design needs refinement! There is ongoing work in #7828, and you may want to talk to Jan Stolarek and Ross Paterson about it. It would be a pity to have two competing patches! Also it'll make it much easier for me (I find arrows difficult) if the arrows community is speaking with one voice about what they want to do. Of course, none of this is to stand in the way of you doing things in a fork of your own -- GHC is an open source project! It's just that if you want your work to be absorbed into HEAD, then the above things become important. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 12:52:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 12:52:54 -0000 Subject: [GHC] #9598: GHC fails to build on Windows because of AMP breakage in haskeline In-Reply-To: <045.fbaf99a5052a962384a061b49eddf557@haskell.org> References: <045.fbaf99a5052a962384a061b49eddf557@haskell.org> Message-ID: <060.40be215b7fa1fee4dc5d6dcd2625b8f6@haskell.org> #9598: GHC fails to build on Windows because of AMP breakage in haskeline -------------------------------------+------------------------------------- Reporter: gintas | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: libraries | Version: 7.9 (other) | Keywords: haskeline Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged (I had an exact same copy of this patch I wrote too in my tree), thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 12:59:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 12:59:22 -0000 Subject: [GHC] #9400: poor performance when compiling modules with many Text literals at -O1 In-Reply-To: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> References: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> Message-ID: <062.3e4d7f1da00879648e0c7c169ad15744@haskell.org> #9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: xnyhps Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9370 Test Case: | Blocking: | Differential Revisions: Phab:D199 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"fe9f7e40844802443315ef2238c4cdefda756b62/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fe9f7e40844802443315ef2238c4cdefda756b62" Remove special casing of singleton strings, split all strings. Summary: exprIsConApp_maybe now detects string literals and correctly splits them. This means case-statemnts on string literals can now push the literal into the cases. fix trac issue #9400 Test Plan: validate Reviewers: austin, simonpj Reviewed By: austin, simonpj Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D199 GHC Trac Issues: #9400 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 12:59:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 12:59:21 -0000 Subject: [GHC] #4290: hClose002 test fails on Solaris/x86 due to bad expected output In-Reply-To: <046.f33011e5dee0b08536c12b8f9def3d93@haskell.org> References: <046.f33011e5dee0b08536c12b8f9def3d93@haskell.org> Message-ID: <061.ae108c7d2a9e05e7d4278a111e2c7923@haskell.org> #4290: hClose002 test fails on Solaris/x86 due to bad expected output -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.9 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: | Difficulty: Easy (less than 1 None/Unknown | hour) Test Case: hClose002 | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"cdf5a1c953c439de9e64a9a8364a2184049b9369/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cdf5a1c953c439de9e64a9a8364a2184049b9369" Add special stdout for hClose002 on x64 Solaris Summary: This is identical to the x86 output from bug #4290, and fixes the hClose002 test when running under x86_64-unknown-solaris2. Test Plan: Re-run 'make TEST=hClose002' under x64 Solaris. Reviewers: ezyang, austin Reviewed By: ezyang, austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D205 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 12:59:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 12:59:22 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.5ab19bcf8cbcaf0b6db2dcc276a8e4d4@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 6.6.1 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"52eab67a99dd928204b730355245233fa96fa24d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="52eab67a99dd928204b730355245233fa96fa24d" Add the ability to :set -l{foo} in ghci, fix #1407. Summary: The dynamic linking code was already there but it was not called on flag changes in ghci. Test Plan: validate Reviewers: hvr, simonmar, austin Reviewed By: austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D194 GHC Trac Issues: #1407 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 12:59:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 12:59:21 -0000 Subject: [GHC] #8148: ./configure IGNORES --with-gcc=gcc-4.8, can't build head on os x 10.8 with xcode 5 installed In-Reply-To: <045.032fb4464ed0b18eaa99793f4a167bc4@haskell.org> References: <045.032fb4464ed0b18eaa99793f4a167bc4@haskell.org> Message-ID: <060.db58c7575c09152bbd2fcf3d95e89349@haskell.org> #8148: ./configure IGNORES --with-gcc=gcc-4.8, can't build head on os x 10.8 with xcode 5 installed ---------------------------------+---------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"cfd8c7ddcdae47fc676d7b16ce8af7b5328a1041/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cfd8c7ddcdae47fc676d7b16ce8af7b5328a1041" Find the target gcc when cross-compiling Summary: "./configure --target=TARGET" was broken; it would use the host gcc. (So you had to explicitly specify "--with-gcc=TARGET-gcc" also, as a workaround.) This was broken by commit fc4856f9e811d9a23ae9212f43a09ddf5ef12b26 for #8148. A comment claimed that FP_ARG_WITH_PATH_GNU_PROG_OPTIONAL was the same as FP_ARG_WITH_PATH_GNU_PROG except for not raising an error when the program isn't found; but that wasn't true -- the former didn't prepend the target name when cross-compiling. We actually need three versions of FP_ARG_WITH_PATH_GNU_PROG since the LLVM tools are usually not prefixed with the target name even when cross-compiling. So I generalized the logic in a single macro. Test Plan: Built with "./configure --target=i386-unknown-linux" and BuildFlavour=quick, successfully Reviewers: ezyang, austin Reviewed By: ezyang, austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D204 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 12:59:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 12:59:22 -0000 Subject: [GHC] #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() In-Reply-To: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> References: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> Message-ID: <068.8d4c1a5952cec7a96dafa4cf4c11fdc5@haskell.org> #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() -------------------------------------+------------------------------------- Reporter: | Owner: AndreasVoellmy | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Incorrect | Related Tickets: 9284 result at runtime | Test Case: | Blocking: | Differential Revisions: Phab:D129 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"7e658bc14e2dd6baf208deebbdab9e1285ce4c72/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7e658bc14e2dd6baf208deebbdab9e1285ce4c72" Revert "Revert "rts/base: Fix #9423"" and resolve issue that caused the revert. Summary: This reverts commit 4748f5936fe72d96edfa17b153dbfd84f2c4c053. The fix for #9423 was reverted because this commit introduced a C function setIOManagerControlFd() (defined in Schedule.c) defined for all OS types, while the prototype (in includes/rts/IOManager.h) was only included when mingw32_HOST_OS is not defined. This broke Windows builds. This commit reverts the original commit and resolves the problem by only defining setIOManagerControlFd() when mingw32_HOST_OS is defined. Hence the missing prototype error should not occur on Windows. In addition, since the io_manager_control_wr_fd field of the Capability struct is only usd by the setIOManagerControlFd, this commit includes the io_manager_control_wr_fd field in the Capability struct only when mingw32_HOST_OS is not defined. Test Plan: Try to compile successfully on all platforms. Reviewers: austin Reviewed By: austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D174 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 13:02:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 13:02:36 -0000 Subject: [GHC] #9596: Create monoidal category framework for arrow desugarer In-Reply-To: <050.5943b671786c1c07283b6317d06d031c@haskell.org> References: <050.5943b671786c1c07283b6317d06d031c@haskell.org> Message-ID: <065.3f230458984a81df302064237560249b@haskell.org> #9596: Create monoidal category framework for arrow desugarer -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh spacekitteh | Status: new Type: task | Milestone: 7.10.1 Priority: normal | Version: Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: #7828 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Speaking of #7828 I have to admit my work on it has stalled in favour of #6018. Sophie, feel free to take over #7828 if you feel like it. I'll be happy to share what I've learnt and implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 13:02:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 13:02:56 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.6b2018c4f34646f72f7985aec9710185@haskell.org> #7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: AlessandroVermeulen | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #1537, #3613 Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D72 | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: jstolarek => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 13:04:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 13:04:40 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.cba7f331637c5766cbab3ac5df06d407@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: => Phab:D202 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 13:10:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 13:10:57 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.272c2e718ffbbdd945eaa4eec759da7b@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's an example where SAT would be a big win. See [http://www.haskell.org/pipermail/ghc-devs/2014-September/006332.html email thread]. {{{ scanr = \ @ a_akP @ a1_akQ f_ah8 b_ah9 eta_B1 -> letrec { go_amb go_amb = \ ds_amc eta1_Xa eta2_B2 eta3_Xc -> case ds_amc of _ { [] -> eta1_Xa eta2_B2 eta3_Xc; : y_amh ys_ami -> go_amb ys_ami (\ x_an9 eta4_Xj -> let { b'_ana b'_ana = f_ah8 y_amh x_an9 } in eta1_Xa b'_ana (: b'_ana eta4_Xj)) eta2_B2 eta3_Xc }; } in go_amb eta_B1 scanr1 b_ah9 (: b_ah9 ([])) }}} The 3rd and 4th arg to `go` are static, and since there is only one call to `go`, doing SAT would yield much better code by specialising `go` for the particular parameters: {{{ scanr = \ @ a_akP @ a1_akQ f_ah8 b_ah9 eta_B1 -> let { listend listend = : b_ah9 ([])} in letrec { go_amb go_amb = \ ds_amc eta1_Xa -> case ds_amc of _ { [] -> eta1_Xa b_ah9 listend; : y_amh ys_ami -> go_amb ys_ami (\ x_an9 eta4_Xj -> let { b'_ana b'_ana = f_ah8 y_amh x_an9 } in eta1_Xa b'_ana (: b'_ana eta4_Xj)) }; } in go_amb eta_B1 scanr1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 13:20:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 13:20:07 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.0f90ba056b49a5d75180dbf2403d5aa4@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 6.6.1 Component: GHCi | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: infoneeded => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 13:20:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 13:20:36 -0000 Subject: [GHC] #9400: poor performance when compiling modules with many Text literals at -O1 In-Reply-To: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> References: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> Message-ID: <062.e8ea5db0e6357c9ef3e2471ee1685a87@haskell.org> #9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: xnyhps Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9370 Test Case: | Blocking: | Differential Revisions: Phab:D199 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Awesome! Merged, thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 13:20:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 13:20:48 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.fd25edd0cb7414b58d63a6a222b0ce68@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 6.6.1 Component: GHCi | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D194 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D194 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 13:22:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 13:22:07 -0000 Subject: [GHC] #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() In-Reply-To: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> References: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> Message-ID: <068.05205817884876c2d2dd585d73c8df61@haskell.org> #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() -------------------------------------+------------------------------------- Reporter: | Owner: AndreasVoellmy | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Incorrect | Related Tickets: 9284 result at runtime | Test Case: | Blocking: | Differential Revisions: Phab:D129 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: OK, this should be fixed For Real this time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 15:23:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 15:23:14 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.a8f6e85c3a8737b29305673079fec32e@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): I've reduced the test case example. It appears to be related to the Generic binary implementation: {{{ {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE DeriveGeneric #-} module Distribution.Version where import Data.Binary ( Binary(..) ) import Data.Data ( Data ) import Data.Typeable ( Typeable ) import GHC.Generics ( Generic ) data T = A | B | C T | D T T | E T T deriving (Data, Generic, Typeable) instance Binary T }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 15:35:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 15:35:56 -0000 Subject: [GHC] #9400: poor performance when compiling modules with many Text literals at -O1 In-Reply-To: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> References: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> Message-ID: <062.f1611c32d958a4eb7c889aca3dc70290@haskell.org> #9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: xnyhps Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9370 Test Case: | Blocking: | Differential Revisions: Phab:D199 | -------------------------------------+------------------------------------- Comment (by rwbarton): By the way, bos has added the rules for Data.Text.fromString on 0- and 1-character literals in text-1.2.0.0, and I confirmed that the original issue of this ticket does not arise with that version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 15:48:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 15:48:38 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.db57db629f414b4fbc07d32dd68f3f28@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: 6086 GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Hi Mikolaj, thanks so much for your work on this! Could you clarify in the very nice wiki page you have created that these instructions pertain to installing the x86 binary distribution on x86_64 systems? Another possible approach is to build one's own x86_64-to-x86 cross-compiler and cross-compiled x86 compiler from source, following the general directions at Building/CrossCompiling. This currently also works fairly well, though I haven't tested it as thoroughly as you have tested running the x86 binary distribution on x86_64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 16:07:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 16:07:51 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.b08d061f77fe5e59ee9d90884030351d@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: 6086 GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I fear it might be difficult, when building the Linux/x86 GHC on an Linux/x86 system, to anticipate all the possible systems that might be capable of building and running Linux/x86 executables (at least Linux/x86_64, but possibly others now or in the future?), and what command-line options the C toolchain needs to build such executables. But here is a slightly different suggestion. Inside `$PREFIX/lib/ghc-7.8.3` you will find a file `settings`, which contains (among other things) the options that GHC passes to the C compiler, linker, etc. GHC reads this file at startup, so you can change any of these settings just by editing the file. Can you see if it is possible to effect all of your needed options like `-optc=-m32` via changes to this `settings` file? Those options should be respected by other Haskell tools like cabal and hsc2hs, so this may fix your other issues automatically. (If those tools do not respect these settings, it is probably a bug in those tools that should be fixed.) If it's not possible because you need (for example) a new setting `"assembler flags"`, it should be fairly easy to add such settings to this file. If the needed changes can be made through the `settings` file, then we won't need to modify GHC itself at all, and we can have the binary distribution `configure` script automatically detect that you are trying to install an x86 GHC on an x86_64 system, and modify the `settings` file accordingly. (By the way I'm a bit confused by your option `-optl-m32`, because my linker doesn't have a `-m32` option, only `-melf_i386`. Does that `-optl-m32` really do anything?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 16:39:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 16:39:07 -0000 Subject: [GHC] #9584: Interface file errors (Iface type variable out of scope: k) In-Reply-To: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> References: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> Message-ID: <065.b1c33f4c5c759324270e202579b1f013@haskell.org> #9584: Interface file errors (Iface type variable out of scope: k) -------------------------------------+------------------------------------- Reporter: | Owner: jonsterling | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): By "bogus" I meant that GHC's behaviour looks very suspicious; a probable bug. But indeed a test case would enable us to find out. Thank you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 16:55:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 16:55:10 -0000 Subject: [GHC] #9530: min / max do not always return the other argument when one of the arguments is NaN In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.e7b068e98ac01767b9674e8acd044122@haskell.org> #9530: min / max do not always return the other argument when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: 9276 Blocking: | Related Tickets: 9276 Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: Replying to [comment:3 dfeuer]: > I think it probably makes sense to have multiple sets of operations available: > > 1. IEEE compliant stuff, whether sane or not. > > 2. Stuff that's fast in hardware, whether sane or not. > > 3. Stuff that's sane. I whole-heartedly agree with this, but, (at most?!) one of these behaviors can be the behavior of the `Ord Double` instance. Any proposed change to that instance needs to be made through the library submissions process, so I'm going to close this ticket as "invalid". This discussion should continue, though! Maybe here, or perhaps on a new wiki page?there are getting to be a number of these tickets on floating-point behavior and it would be good to have all the discussion in one place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 17:11:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 17:11:43 -0000 Subject: [GHC] #9528: typo in man-page/docs In-Reply-To: <048.b394457866f8d569617be702e8907986@haskell.org> References: <048.b394457866f8d569617be702e8907986@haskell.org> Message-ID: <063.d911fc0708d1d6957de4a07ede5d060c@haskell.org> #9528: typo in man-page/docs -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"e7a0f5b66ced8d56d770375e4d35d38c70067559/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e7a0f5b66ced8d56d770375e4d35d38c70067559" Fix typo "Rrestriction" in user's guide (lspitzner, #9528) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 17:12:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 17:12:12 -0000 Subject: [GHC] #9528: typo in man-page/docs In-Reply-To: <048.b394457866f8d569617be702e8907986@haskell.org> References: <048.b394457866f8d569617be702e8907986@haskell.org> Message-ID: <063.4133519971a3a384993c9113d7b1f103@haskell.org> #9528: typo in man-page/docs -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: Thanks for the report, fixed in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 17:24:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 17:24:33 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.e6942022790791f7a90ba35bb728369a@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): FWIW I don't regard `ScopedTypeVariables` as changing the semantics of `forall`. Rather it changes the meaning of type variables in type ascriptions and non-top-level type declarations depending on whether those variables were mentioned in a particular syntactic form involving `forall`. As such I don't experience any cognitive dissonance when thinking about ExplicitForall, RankNTypes, ScopedTypeVariables, and their various combinations. I realize that this is a subtle distinction and that `ScopedTypeVariables` is often described as bestowing a special new meaning on the keyword `forall`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 17:35:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 17:35:17 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.7aa5111ae832f74b607fa638e1aa24cf@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by rwbarton): I would just like to echo comment:16: it would be REALLY great not to commit to a particular implementation of `unStatic` such as `dlsym()`; in particular the GHCJS backend should be able to have its implementation of the same functionality, with compatible `StaticName` serializations (if not downright compatible `StaticName` types). That opens up very interesting possibilities for pure Haskell client/server web applications. As a more technical point, since GHCJS does dead code elimination, there should be some means by which the GHCJS code generator can know which top- level values are the referents of `static` expressions, so it can treat them as live, without having to pessimistically assume that everything is live. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 17:45:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 17:45:41 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.ed2a12a7be8bc8d27527b6750d4e7a26@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: enum01.hs | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:6 jrp]: > I think that the test should be fixed to make it Clang-compatible. That way it will test enum, which is what it is supposed to do. The same applies to enum02-04. Agreed. Would you like to prepare a patch? I expect all that's needed is to remove all the spaces after occurrences of `printTest`. (Otherwise I will get around to it eventually.) > We should then have another test specifically for cpp behaviour. (I would do this, but don't have commit access.) So I take it the test fails for you with WAY=ghci, but not any of the other ways? That's a bit perplexing and deserves a test, yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 18:09:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 18:09:52 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.f03f96d8fb40deb32122c6468c160a82@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * blockedby: 6086 => Comment: (The problem here isn't that we aren't passing ld flags to cabal, rather that we don't know what the right ld flags are at all.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 18:20:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 18:20:20 -0000 Subject: [GHC] #9562: Type families + hs-boot files = unsafeCoerce In-Reply-To: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> References: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> Message-ID: <062.9a4e510758ae0bf42a39a29cec9e6d78@haskell.org> #9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by adamgundry): Ouch! I conjecture that the following lighter restriction will restore type soundness: a hs-boot file must list all type instance declarations used (transitively) in the typechecking of any definition whose declaration appears in the hs-boot file. (That is, a type instance declaration must be listed if its axiom would appear in the fully-unfolded elaborated Core term corresponding to any declaration in the hs-boot file.) Even if this conjecture is correct, of course, this may be unreasonably hard to implement/explain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 18:27:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 18:27:10 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.7b095821e1ee7b1e04cd856e504cd3ae@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Try applying https://phabricator.haskell.org/D208 to HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 20:08:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 20:08:41 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.8b87319acd5779bdd9295931eac8378f@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): The easiest thing to do is...nothing. That will not break anyone's code. I agree it might be neater to do something else, but it seems to be causing more trouble than it's worth. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 20:12:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 20:12:28 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.8bb48551606bcae4f3172262387fc3b9@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Agreed. No way should the design mandate any particular implementation for `unStatic`! My current proposals are outlined here [blog:simonpj/StaticPointers]. There is haze around Plan A/B/C near the end, but I'm veering towards some variant of Plan A. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 20:28:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 20:28:27 -0000 Subject: [GHC] #9599: app runs 10 times faster when compiled with profilling information than without it Message-ID: <046.8ed82e950558f4005f25e1c4df3b6688@haskell.org> #9599: app runs 10 times faster when compiled with profilling information than without it -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Solaris Architecture: x86 | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hello, I've found interesting application code which when compiled with {{{ -O2 -threaded --make }}} runs 10 times slower than the same code compiled with {{{ -O2 -threaded --make -prof -auto-all -caf-all -fforce-recomp }}} the application is compiled by GHC 7.8.2 on i386-solaris2 platform. The profiling application is then run as normal application, i.e. without +RTS -p. The application itself is my crude beginner Haskell code which takes Wikipedia dump (XML file) and tries wiki pages from there import into XWiki using REST API. It uses Data.Text package for lazy load of Wikipedia data, whole logic of selection of page/title/content is done on Data.Text and later saved into XPage which is using ByteString. The application also uses Simon Marlow's Async/async/wait code which is copied from Simon Marlow's Parallel and Concurrent Programming in Haskell http://chimera.labs.oreilly.com/books/1230000000929 App attached. My question is, what to do with it to help finding the issue? E.g. I assume it's issue when profiling app is that much faster than common optimized app. For your information, optimized app takes 9m50s to upload 1000 pages while profiled optimized app takes only 50s to upload the same amount of pages on my equipped with E5-2620 (2 GHz 6 core/12 threads xeon) Also the difference in time is that big that it's not caused by a noise in import of pages on XWiki side. I've tested several times of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 20:59:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 20:59:28 -0000 Subject: [GHC] #9599: app runs 10 times faster when compiled with profilling information than without it In-Reply-To: <046.8ed82e950558f4005f25e1c4df3b6688@haskell.org> References: <046.8ed82e950558f4005f25e1c4df3b6688@haskell.org> Message-ID: <061.28f01658c1c38b6d30dd93056b9ffde6@haskell.org> #9599: app runs 10 times faster when compiled with profilling information than without it -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): The presence of SCC annotations can inhibit certain optimizations; perhaps one of those optimizations is in fact making your non-profiled program much slower. I'd try building it with `-fno-full-laziness` and/or `-fno- state-hack`. For that matter, what is the performance like of the two versions with optimizations turned off completely? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 21:10:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 21:10:01 -0000 Subject: [GHC] #9600: Bad error message: Applicative is not a derivable class Message-ID: <042.64352bf7acca582cb0ead8359109244c@haskell.org> #9600: Bad error message: Applicative is not a derivable class -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- You have `GeneralizedNewtypeDeriving` on and use `deriving Applicative` with something that you cannot derive Applicative on, GHC correctly says `cannot eta-reduce the representation type enough`. If you don't have `GeneralizedNewtypeDeriving` on yet and deriving Applicative will work, GHC says something like "perhaps you want to enable GeneralizedNewtypeDeriving"? However, if you don't have `GeneralizedNewtypeDeriving` AND if GHC figures out that if you enable it, the next message will be `cannot eta-reduce the representation type enough`, then GHC will state the most unhelpful `Applicative is not a derivable class`, which suggests to me that '''in general''', Applicative is not derivable (which is wrong). rwbarton's suggestion: Suggest enabling `GeneralizedNewtypeDeriving` in any case and then let the user see why it cannot be derived. Some relevant #ghc chat: {{{ rwbarton, that's GND again rwbarton: I a ~ K a where K = ErrorT ImmError (ReaderT CliOptions (ReaderT Config IO)) is an instance of Applicative rwbarton: so it can coerce the instance for K to an instance for I nh2: so is it the error message that is the confusing part here? It suggests that "In general, Applicative is not derivable" nh2: I mean it as: Shouldn't it give an error message like "can't derive an Applicative instance in this case because ..."? rwbarton: well maybe it could add something like "Did you mean to use GeneralizedNewtypeDeriving?" rwbarton: oh I see what you mean, even if you turn that extension on it gives the same error message nh2: yes, because we already have such a message in some cases nh2: no, in this case I had really forgotten the extension. If I add it, I get the "cannot eta-reduce the representation type enough" error, but I haven't figured out why I get it in this case yet rwbarton: I wrote the condition above basically, "I a ~ K a where K = ... is an instance of Applicative" where ~ is the coercion/isomorphism introduced by the newtype rwbarton: if you can't write down K then you can't use GND because where would it get the instance? rwbarton: writing down K is eta reduction nh2: I'm wondering whether it doesn't suggest adding the extension because it already figured out I will not be able to eta-reduce? rwbarton: oh yeah, it seems so rwbarton: that seems a bit silly nh2: in this case, I think we should pimp the error message a bit nh2: (this is the thing I want to derive bwt: https://github.com /ganeti-github-testing/ganeti- test-1/blob/master/src/Ganeti/BasicTypes.hs#L147) nh2: what do you think would be the best error message to show in such a case? nh2: just suggest the GNTD suggestion regardless and let the user see afterwards that it cannot work? rwbarton: I would just have it always suggest GND ... yeah nh2: ok I file a ticket for that rwbarton: seems like more suggestions > fewer suggestions rwbarton: even if this is a weird second-order case where there are two errors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 16 23:07:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Sep 2014 23:07:40 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.0ed33065490ffb0239f9325154e3b9b0@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => new Comment: Letting `reverse` fuse with `foldr` generally seems to be causing more than its fair share of problems, including issues relating to arity analysis. I've been working today on different implementations of `dropWhileEnd`. One I think seems particularly pleasant looks like this: {{{#!hs dropWhileEnd p xs = build (\c n -> foldr (dweFB p c) (const n) xs []) {-# INLINE dropWhileEnd #-} dweFB p c = \x r trues -> if p x then r (x : trues) else foldr c (x `c` r []) (reverse trues) }}} I tested this like so: {{{#!hs testDWE = foldl (*) 1 $ dropWhileEnd (>10) [1::Int .. 1000] }}} If `reverse` is prevented from fusing with `foldr`, this generates what looks to me like very good code (note: if you're looking at the Core, that inner `letrec` becomes a let-no-escape), generating far fewer conses and boxes than the current implementation, even if that one is made `INLINE`. If they're allowed to fuse, however, Call Arity fails to work its magic, and the result is a higher-order mess. So I think for now the answer is probably to just use something like the Report Prelude version that fuses with a `build` but not a `foldr`, and add a rule to exchange `map` with `reverse` in some fashion. I'll come up with a patch to do that shortly. Of course, if Joachim or someone can figure out a better solution or a better characterization of the problem, that'd be great. Side note: for reasons I can't begin to figure out, if the `foldl` above is replaced with `foldl'`, then it doesn't fuse at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 05:27:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 05:27:38 -0000 Subject: [GHC] #9596: Create monoidal category framework for arrow desugarer In-Reply-To: <050.5943b671786c1c07283b6317d06d031c@haskell.org> References: <050.5943b671786c1c07283b6317d06d031c@haskell.org> Message-ID: <065.85bc5876d7a0718814a4b9d0a8221595@haskell.org> #9596: Create monoidal category framework for arrow desugarer -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh spacekitteh | Status: new Type: task | Milestone: 7.10.1 Priority: normal | Version: Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: #7828 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spacekitteh): Will do, Simon! I'm just throwing together a quick preliminary design to put up there. Ironically, I need injective type families to provide some of the nicer things such as automatic instances for when symmetric categories implement a left or right class; the compiler gets upset at the ID type family for the monoidal category. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 07:23:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 07:23:46 -0000 Subject: [GHC] #9601: Make the rewrite rule system more powerful Message-ID: <050.d0198153d3c3c67b578255419aefe8e8@haskell.org> #9601: Make the rewrite rule system more powerful -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more | Type of failure: than a week) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be amazing if the current RULES system could be upgraded to include various predicates, or even into a full-on strategic programming system. This would allow far far more optimisations to be possible, rather than the current conservative system where you have to make sure that the optimisations ALWAYS apply. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 07:26:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 07:26:36 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.ec9445ffba0cffe9d246a38e621620d3@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Here's a comment from Phab that should feed into the design: The current implementation does not appear to keep the heap references alive correctly: {{{ {-# LANGUAGE StaticValues #-} module Main where import GHC.Ref import Control.Concurrent import System.Environment import System.Mem import System.Mem.Weak import Data.Numbers.Primes -- from Numbers -- Just a Ref to some CAF from another package so that we can deRef it when linked with -dynamic primes_ref :: Ref [Integer] primes_ref = static primes main = do as <- getArgs let z = primes!!(length as+200) print z performGC -- addFinalizer z (putStrLn "finalizer z") print z performGC threadDelay 1000000 print . fmap (!!300) =<< deRef primes_ref -- uncommenting the next line keeps primes alive and prevents the segfault -- print (primes!!300) }}} and {{{ $ ghc -dynamic -o primes primes.hs [1 of 1] Compiling Main ( primes.hs, primes.o ) Linking primes ... $ ./primes 1229 1229 Segmentation fault (core dumped) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 07:31:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 07:31:00 -0000 Subject: [GHC] #9599: app runs 10 times faster when compiled with profilling information than without it In-Reply-To: <046.8ed82e950558f4005f25e1c4df3b6688@haskell.org> References: <046.8ed82e950558f4005f25e1c4df3b6688@haskell.org> Message-ID: <061.a0e5add8d8652fbfd7863d4fb53afbb8@haskell.org> #9599: app runs 10 times faster when compiled with profilling information than without it -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Another way to get some insight into what is going on is to use `-ticky`. See [wiki:Debugging/TickyTicky]. Reid's instincts about what to try are spot on: try those things too. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 10:20:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 10:20:11 -0000 Subject: [GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. In-Reply-To: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> References: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> Message-ID: <058.0922e3a28f7b18c845e7f859cdc83b69@haskell.org> #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: type family, Resolution: | ambiguity check Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by oleg): I have checked with GHC 7.4.1 as well. It does report the error you quote. And yet the code did work back in 2010 at least, and inferred the type mentioned in my original Trac submission. The change in type inference must have happened sometime around GHC 7.2->7.4. It did break the code, some of which I had to rewrite (and the rest just abandoned). Let's look at the error message closely: {{{ Could not deduce (Arr repr (Arr repr a4 a3) (Arr repr a4 b) ~ Arr repr (Arr repr a2 a1) (Arr repr a2 b0)) from the context (ESymantics repr, Arr repr a3 a ~ Arr repr a4 a3, Arr repr a b ~ Arr repr a4 a3) }}} Since Arr is a function, then choosing a2~a4, a1~a3, b0~b will certainly satisfy the offending constraint. Since the type variables a2, a1, b0 are not mentioned anywhere else, there is no risk of conflicts. I think that's what GHC 7.0 (or 7.2) must have done. True, we must have lost principality. But the principality was lost already in Haskell98, so there is no use to worry about it now. I cannot help but notice the irony: type functions were introduced in 2005 as a `functional' alternative to functional dependencies. Programming with functional dependencies was viewed as logic programming. We are functional programmers, we should program with functions. the slogan went. Alas, when it comes to inference, we need to know what can we infer about t1 and t2 from Fn t1 ~ Fn t2. So, we do have to think relationally rather than functionally -- it is inherent. We have not escaped from the relational view -- merely made it harder to see, which is not always an advantage. BTW, adding the declaration for injective type families may be not enough. For example, consider our Arr repr t1 t2. It could be that Arr repr t1 t2 is injective only for specific repr. We intend to use our example only with such repr. But Arr repr t1 t2 may be usable for different repr, which do not correspond to injective Arr repr. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 10:26:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 10:26:02 -0000 Subject: [GHC] #9600: Bad error message: Applicative is not a derivable class In-Reply-To: <042.64352bf7acca582cb0ead8359109244c@haskell.org> References: <042.64352bf7acca582cb0ead8359109244c@haskell.org> Message-ID: <057.9c7e7bc2f7fab9a523941205dd484743@haskell.org> #9600: Bad error message: Applicative is not a derivable class -------------------------------------+------------------------------------- Reporter: nh2 | Owner: JohnWiegley Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by JohnWiegley): * owner: => JohnWiegley -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 10:26:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 10:26:32 -0000 Subject: [GHC] #9600: Bad error message: Applicative is not a derivable class In-Reply-To: <042.64352bf7acca582cb0ead8359109244c@haskell.org> References: <042.64352bf7acca582cb0ead8359109244c@haskell.org> Message-ID: <057.10600291e721807a1805d6a05aff8b2d@haskell.org> #9600: Bad error message: Applicative is not a derivable class -------------------------------------+------------------------------------- Reporter: nh2 | Owner: JohnWiegley Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by JohnWiegley): Fix pending review: https://phabricator.haskell.org/D216 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 10:27:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 10:27:01 -0000 Subject: [GHC] #9600: Bad error message: Applicative is not a derivable class In-Reply-To: <042.64352bf7acca582cb0ead8359109244c@haskell.org> References: <042.64352bf7acca582cb0ead8359109244c@haskell.org> Message-ID: <057.3ae64780e4e533357326ee0c9ff2c2b4@haskell.org> #9600: Bad error message: Applicative is not a derivable class -------------------------------------+------------------------------------- Reporter: nh2 | Owner: JohnWiegley Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D216 | -------------------------------------+------------------------------------- Changes (by JohnWiegley): * differential: => Phab:D216 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 11:37:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 11:37:36 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.54dffaec6a494cb93a8ea8de573d0d9c@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): I've made a major update to the wiki page. Here are a few things worth pointing out: In [wiki:InjectiveTypeFamilies#Proposedsyntax this section] I've listed all the syntax proposals made so far. I've also [http://www.haskell.org/pipermail/haskell-cafe/2014-September/116065.html mailed Haskell-cafe] so we can get some feedback from the community. I christened various flavours of injectivity as A, B and C :-) -- see [wiki:InjectiveTypeFamilies#Formsofinjectivity this section]. I will refer to them as such in the rest of this comment. I mailed Conal Elliot and he says he does not remember what was his use case for type families injective in only one argument. This means we only have use cases of the form A shown by Simon. Given that, I believe that it is best if we limit ourselves to implementing A. We can revise this design later if someone demonstrates compelling examples of B or C. I have outlined my idea for the algorithm that would verify users injectivity declarations in [wiki:InjectiveTypeFamilies#Implementationoutline this section]. Simon, please tell me if there are any misconceptions about how GHC's type inference works. After some thinking I am against inferring injectivity for closed type families - see my arguments in [wiki:InjectiveTypeFamilies#Inferringinjectivity this section]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 13:12:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 13:12:09 -0000 Subject: [GHC] #9599: app runs 10 times faster when compiled with profilling information than without it In-Reply-To: <046.8ed82e950558f4005f25e1c4df3b6688@haskell.org> References: <046.8ed82e950558f4005f25e1c4df3b6688@haskell.org> Message-ID: <061.cf5dbdf26c1e9e75b5aa1884e07c664f@haskell.org> #9599: app runs 10 times faster when compiled with profilling information than without it -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by kgardas): Based on the feedback I'm adding time testing with several combinations of GHC options. I'm benchmarking here 1000 pages import like in the original report. Time around 40s is computerd as average from several runs. Time in minutes is from one run. ||time||options|| ||40s||--make|| ||40s||--make -prof -auto-all -caf-all -fforce-recomp|| ||39s||-threaded --make|| ||40s||-threaded --make -prof -auto-all -caf-all -fforce-recomp|| ||9m12s||-O -threaded --make|| ||9m40s||-O -threaded --make -fno-full-laziness|| ||15m3s||-O -threaded --make -fno-state-hack|| ||40s||-O -threaded --make -prof -auto-all -caf-all -fforce-recomp|| I'll see yet what I can do with -ticky suggestion here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 15:01:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 15:01:50 -0000 Subject: [GHC] #9602: compiling arithmoi with llvm 3.5.0-2.1 generates an LLVM compilation error Message-ID: <045.7302f283c90f233daf6c88b59d56b601@haskell.org> #9602: compiling arithmoi with llvm 3.5.0-2.1 generates an LLVM compilation error -------------------------------------+------------------------------------- Reporter: ryantm | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hello. I know llvm 3.5.0 is not supported by GHC, but I thought it might be nice to have a report of a problem with it for the time when someone wants to start supporting it. I'm sorry if this is not a bug with GHC. I tried to compile arithmoi-0.4.1.1 via cabal install and here is the output received: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 $ cabal --version cabal-install version 1.20.0.3 using version 1.20.0.1 of the Cabal library $ uname -a Linux hostname 3.16.1-1-ARCH #1 SMP PREEMPT Thu Aug 14 07:40:19 CEST 2014 x86_64 GNU/Linux $ pacman -Q llvm llvm 3.5.0-2.1 $ cabal install arithmoi-0.4.1.1 Resolving dependencies... Configuring arithmoi-0.4.1.1... Building arithmoi-0.4.1.1... Preprocessing library arithmoi-0.4.1.1... [ 1 of 34] Compiling Math.NumberTheory.Primes.Sieve.Indexing ( Math/NumberTheory/Primes/Sieve/Indexing.hs, dist/dist-sandbox- f1ff1bf8/build/Math/NumberTheory/Primes/Sieve/Indexing.o ) You are using a new version of LLVM that hasn't been tested yet! We will try though... Alias must point to a definition i8* @"integerzmgmp_GHCziIntegerziType_Szh_static_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTypes_Izh_static_info$alias" Alias must point to a definition i8* @"base_GHCziReal_zdp1Integral_info$alias" Alias must point to a definition i8* @"stg_upd_frame_info$alias" Alias must point to a definition i8* @"base_GHCziReal_zdp1Real_info$alias" Alias must point to a definition i8* @"stg_ap_p_info$alias" Alias must point to a definition i8* @"base_GHCziNum_fromInteger_info$alias" Alias must point to a definition i8* @"base_GHCziReal_toInteger_info$alias" Alias must point to a definition i8* @"integerzmgmp_GHCziIntegerziType_integerToInt_info$alias" Alias must point to a definition i8* @"stg_ap_0_fast$alias" Alias must point to a definition i8* @"stg_ap_pp_info$alias" Alias must point to a definition i8* @"base_GHCziNum_zm_info$alias" Alias must point to a definition i8* @"stg_gc_unbx_r1$alias" Alias must point to a definition i8* @"base_GHCziReal_quotRem_info$alias" Alias must point to a definition i8* @"stg_sel_1_upd_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTypes_Izh_con_info$alias" Alias must point to a definition i8* @"stg_sel_0_upd_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTuple_Z2T_con_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTypes_ZC_static_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTypes_ZMZN_closure$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTuple_Z0T_closure$alias" Alias must point to a definition i8* @"stg_newByteArrayzh$alias" Alias must point to a definition i8* @"stg_gc_unpt_r1$alias" Alias must point to a definition i8* @"arrayzm0zi5zi0zi0_DataziArrayziBase_UArray_con_info$alias" Alias must point to a definition i8* @"newCAF$alias" Alias must point to a definition i8* @"stg_bh_upd_frame_info$alias" Alias must point to a definition i8* @"base_GHCziST_runSTRep_info$alias" Alias must point to a definition i8* @"integerzmgmp_GHCziIntegerziType_smallInteger_info$alias" Alias must point to a definition i8* @"stg_ap_p_fast$alias" Alias must point to a definition i8* @"stg_ap_pp_fast$alias" LLVM ERROR: Broken module found, compilation aborted! Failed to install arithmoi-0.4.1.1 cabal: Error: some packages failed to install: arithmoi-0.4.1.1 failed during the building phase. The exception was: ExitFailure 1 }}} Ryan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 15:02:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 15:02:41 -0000 Subject: [GHC] #9602: compiling arithmoi with llvm 3.5.0 generates an LLVM compilation error (was: compiling arithmoi with llvm 3.5.0-2.1 generates an LLVM compilation error) In-Reply-To: <045.7302f283c90f233daf6c88b59d56b601@haskell.org> References: <045.7302f283c90f233daf6c88b59d56b601@haskell.org> Message-ID: <060.a013c4a61fd56b8bd73df7a18cd3ae79@haskell.org> #9602: compiling arithmoi with llvm 3.5.0 generates an LLVM compilation error -------------------------------------+------------------------------------- Reporter: ryantm | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 (LLVM) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 15:58:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 15:58:30 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.aef1c7c83b1280df6dc06c7dd988d257@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries | Version: (other) | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"b62bd5ecf3be421778e4835010b6b334e95c5a56/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b62bd5ecf3be421778e4835010b6b334e95c5a56" Implement `decodeDouble_Int64#` primop The existing `decodeDouble_2Int#` primop is rather inconvenient to use (and in fact is not even used by `integer-gmp`) as the mantissa is split into 3 components which would actually fit in an `Int64#` value. However, `decodeDouble_Int64#` is to be used by the new `integer-gmp2` re-implementation (see #9281). Moreover, `decodeDouble_2Int#` performs direct bit-wise operations on the IEEE representation which can be replaced by a combination of the portable standard C99 `scalbn(3)` and `frexp(3)` functions. Differential Revision: https://phabricator.haskell.org/D160 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 16:12:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 16:12:15 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.f203a00de2a95fe0ac65cd3a6879aaaf@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by luite): I agree with simonpj and rwbarton. My suggestion in the phab discussion (generating foreign exports) was merely something that could be done with the current tools, but now that the patch is going to be rewritten/improved there may be better options. Other than getting memory management sorted out, I think these are the minimum requirements to make it possible to implement static values properly on different backends: * GHC should explicitly keep track of all static metadata (hi files probably) * Static names would propagate like typeclass instances * It should be possible to build a list (like the Static Pointer Table) at link time for a library or program (and if desired, build a program that can produce this list at runtime) * `StaticName` should be reasonably robust against minor variations between compiles/backends * no backend/platform specific internal names * a source code location as an identifier for generated names is better than a simple counter * at least some simple safeguard against constructing an ill-typed heap object (like a type fingerprint) should be there As an aside, I think it would be really useful if there was a way to send type details with a more complete serialization of the construction (in terms of `Typeable`/`TypeRep` or similar) in the `StaticName` or at a higher level: * It would be possible to generate a more readable type error message if a fingerprint does not match (rather than using `show` on both sides) * Languages like Python and JavaScript could dynamically convert values * In conjunction with `GHC.Generics` or `Data.Data` one could use this to generate user interfaces that allow typesafe structured construction/editing of arguments (and dictionaries, when supported) And a final point on my wish list: It would be very useful if the `static` keyword for toplevel bindings would result in a `StaticName` that uses the original function name, rather than some generated name: {{{ #!haskell import qualified Data.Map as M -- this would guarantee that concat is in the static list concat :: [[a]] -> [a] concat = static (foldr (++) []) -- for functions that do pattern matching we could introduce a pragma {-# STATIC and #-} and :: [Bool] -> Bool and [] = True and (x:xs) = x && and xs -- or for exposing functions from other modules {-# STATIC M.fromList #-} }}} This would make it easier to have asymmetric CH programs, where one part is merely the callee, but does not include the code where the result from the call is used. I think this could also useful to implement a more flexible foreign exports mechanism for GHCJS, see https://github.com/ghcjs/ghcjs/issues/194 for some discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 16:39:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 16:39:33 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.2eb6e09a79129d5f53698b898b3dd605@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by JohnWiegley): Simon and I had a look at this, and we found a few more data points: 1. Manually implementing {{{get}}} and {{{put}}} for the instance, even if just to copy the default definitions, causes the test case above to pass. 2. The following data type also reproduces the problem: {{{ data T = A T T T T T T T T T T T T | B T deriving (Data, Typeable, Generic) }}} 3. If you implement {{{get}}} for the instance, but not {{{put}}}, the error still occurs; but the converse works. 4. If you set {{{put = gdmput}}}, and then define it in its own module, marking it INLINE works, but INLINEABLE fails: {{{ gdmput :: (Generic t, GBinary (Rep t)) => t -> Put gdmput = gput . from {-# INLINABLE gdmput #-} }}} 5. Displaying inlining information with {{{-ddump-inlinings -ddump-rule- firings}}} shows that after the first few unfoldings, the following repeats continually up until the failure. Increasing the tick cause simply causes more of this occurrence to display: {{{ Rule fired: Class op gput Rule fired: Class op gput Rule fired: Class op gput Rule fired: Class op gput Inlining done: Data.Binary.Generic.unTagged Inlining done: Data.Binary.Generic.unTagged1 Inlining done: GHC.Base.id Inlining done: GHC.Word.$fOrdWord64_$c<= Inlining done: GHC.Word.$fNumWord64_$c- Inlining done: Data.Binary.Generic.$fSumSizeM1_$csumSize Inlining done: Data.Binary.Generic.$fSumSizeM1_$csumSize Rule fired: plusWord# Inlining done: GHC.Word.$fBitsWord64_$cfromInteger Rule fired: integerToWord Rule fired: minusWord# Rule fired: leWord# Rule fired: tagToEnum# Inlining done: GHC.Word.$fBitsWord8_$cfromInteger Rule fired: integerToWord Rule fired: narrow8Word# Inlining done: Data.Binary.Generic.$fSumSizeM1_$csumSize Inlining done: Data.Binary.Generic.$fSumSizeM1_$csumSize Rule fired: plusWord# Inlining done: GHC.Base.id Rule fired: narrow8Word# Inlining done: GHC.Word.$fBitsWord8_$cshiftR Rule fired: >=# Rule fired: tagToEnum# Rule fired: uncheckedShiftRL# Rule fired: Class op putSum Inlining done: Data.Binary.Put.$fApplicativePutM_$c*> Inlining done: Data.Binary.Put.$fApplicativePutM2 Rule fired: Class op put Inlining done: Data.Binary.Put.putWord8 Inlining done: GHC.Base.$ Inlining done: GHC.Base.returnIO Inlining done: GHC.Base.returnIO1 Inlining done: GHC.Base.bindIO Inlining done: GHC.Base.bindIO1 Inlining done: GHC.Base.flip Inlining done: Foreign.Storable.$fStorableWord8_$cpoke Inlining done: Foreign.Storable.$fStorableWord19 Rule fired: Class op gput Inlining done: GHC.Word.$fNumWord8_$c+ Rule fired: plusWord# Rule fired: narrow8Word# Inlining done: GHC.Word.$fNumWord8_$c- Rule fired: minusWord# Rule fired: narrow8Word# Rule fired: Class op putSum Inlining done: Data.Binary.Put.$fApplicativePutM_$c*> Inlining done: Data.Binary.Put.$fApplicativePutM2 Rule fired: Class op put Inlining done: Data.Binary.Put.putWord8 Inlining done: GHC.Base.$ Inlining done: GHC.Base.returnIO Inlining done: GHC.Base.returnIO1 Inlining done: GHC.Base.bindIO Inlining done: GHC.Base.bindIO1 Inlining done: GHC.Base.flip Inlining done: Foreign.Storable.$fStorableWord8_$cpoke Inlining done: Foreign.Storable.$fStorableWord19 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 17:02:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 17:02:47 -0000 Subject: [GHC] #9602: compiling arithmoi with llvm 3.5.0 generates an LLVM compilation error In-Reply-To: <045.7302f283c90f233daf6c88b59d56b601@haskell.org> References: <045.7302f283c90f233daf6c88b59d56b601@haskell.org> Message-ID: <060.5f6e4c6a51e5c869c0b6bd882afd54c0@haskell.org> #9602: compiling arithmoi with llvm 3.5.0 generates an LLVM compilation error -------------------------------------+------------------------------------- Reporter: ryantm | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.3 (LLVM) | Keywords: Resolution: duplicate | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. We have a ticket for this already, #9142. I'll prod it a bit. For arithmoi in particular, you can build it with the cabal flag `-fno- llvm`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 17:03:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 17:03:40 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.a7e3f00b2f33b51033cdaabc8c23ee76@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 4213 | Differential Revisions: Phab:D155 | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D155 Comment: What's the status of this, waiting on review? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 17:14:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 17:14:43 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.074958dff09d2dc82715c7760e347390@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 4213 | Differential Revisions: Phab:D155 | -------------------------------------+------------------------------------- Comment (by bgamari): Yep; my initial concern was that a deeper refactoring was necessary to fix this cleanly but looking back over the patch it's not nearly as invasive as I recall. It could probably be merged as-is after review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 17:19:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 17:19:25 -0000 Subject: [GHC] #9584: Interface file errors (Iface type variable out of scope: k) In-Reply-To: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> References: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> Message-ID: <065.eb562477230b214f68d6f7fdd5e92140@haskell.org> #9584: Interface file errors (Iface type variable out of scope: k) -------------------------------------+------------------------------------- Reporter: | Owner: jonsterling | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9263 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * related: => #9263 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 18:01:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 18:01:12 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.199489e97acb2e112e267784de1a2666@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: enum01.hs | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): I think that that is right: {{{ ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded,optllvm) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded,optllvm) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded,optllvm) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) }}} (Could I leave it to you for the patches, as I don't have commit access.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 18:10:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 18:10:07 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.0dc481f4259fa82917ae5a15f9d5759f@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: enum01.hs | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => rwbarton Comment: Oh, so it is failing in all WAYs, good, that makes more sense. Sure, I will adjust the tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 19:10:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 19:10:00 -0000 Subject: [GHC] #4218: System.Random is way too lazy In-Reply-To: <048.0b01b9721d2535305bd4a9089fdf6d96@haskell.org> References: <048.0b01b9721d2535305bd4a9089fdf6d96@haskell.org> Message-ID: <063.cda0dc3c0b4a8fc2a8c84d9e06614c9b@haskell.org> #4218: System.Random is way too lazy -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: | Version: 6.12.3 libraries/random | Keywords: random stack Resolution: fixed | overflow Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 427, 7936 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * status: patch => closed * resolution: => fixed Comment: Shipped in random 1.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 19:10:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 19:10:43 -0000 Subject: [GHC] #8899: StdGen does not generate 0 In-Reply-To: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> References: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> Message-ID: <065.783f4a3f3d6752e0a73b3fd6a446a96e@haskell.org> #8899: StdGen does not generate 0 -------------------------------------+------------------------------------- Reporter: | Owner: ekmett novadenizen | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: | Keywords: libraries/random | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): Fixed in random 1.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 19:13:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 19:13:05 -0000 Subject: [GHC] #427: Random.StdGen slowness In-Reply-To: <044.910d2f7eb299e5f5b612cc8fccf049ef@haskell.org> References: <044.910d2f7eb299e5f5b612cc8fccf049ef@haskell.org> Message-ID: <059.d93ea716041097ea5f99e186f0e9de8f@haskell.org> #427: Random.StdGen slowness -------------------------------------+------------------------------------- Reporter: remit | Owner: rrnewton Type: bug | Status: new Priority: normal | Milestone: ? Component: | Version: libraries/random | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: rrnewton (added) Comment: The "thunk-bomb" problem should be fixed in random 1.1. The redesign question is still, however, open. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 19:13:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 19:13:24 -0000 Subject: [GHC] #427: Random.StdGen slowness In-Reply-To: <044.910d2f7eb299e5f5b612cc8fccf049ef@haskell.org> References: <044.910d2f7eb299e5f5b612cc8fccf049ef@haskell.org> Message-ID: <059.2df7608e6d2659fe1d3af3021a2ebbe2@haskell.org> #427: Random.StdGen slowness -------------------------------------+------------------------------------- Reporter: remit | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ? Component: | Version: libraries/random | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * owner: rrnewton => ekmett -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 19:48:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 19:48:25 -0000 Subject: [GHC] #9603: getArgs path transformation is broken on Windows Message-ID: <045.e61ab36b85802c1081d92cfe8af2fe04@haskell.org> #9603: getArgs path transformation is broken on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It looks like System.Environment.getArgs is trying to be smart on Windows and to transform arguments drive paths to environment-local paths (e.g., 'C:/' => 'C:\msys64', but it messes up the mangling somewhere if the path is not at the beginning of the argument: $ args "C:/" ["C:/"] $ /tmp/args " C:/" [" C;C:\\msys64"] Note the leading "C;" which makes no sense. $ uname -s MINGW64_NT-6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 19:54:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 19:54:02 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.e1e84b627d358b4e742340097bb309a4@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Luite, much of what you say is cast in terms of an underlying implementation, whereas my blog post focuses as exclusively as possible on the ''specification'' of what the programmer sees. Can you recast your suggestions in those terms? For example: * What does it mean to say that "GHC should explicitly keep track of all static metadata"? How would a programmer be able to tell whether or not GHC did so. That is, what programmer-visible behaviour do you seek? * Again "It should be possible to build a list (like the Static Pointer Table) at link time for a library". This is presumably a statement about the implementation but again you must have in mind some user-visible behavior? What is it? * Again "Static names would propagate like typeclass instances". I don't really know what this means, but specifically how would a programmer know if this happened? Static names are not visible to the programmer in the design I suggest; I use them only so I can say something about a possible implementation. All the programmer sees is ordinary Haskell values and types (with one new type constructor, `StaticPtr`. * "`StaticName` should be reasonably robust..." Again, you must have in mind some user-visible behaviour. Here I think I do know what you might mean. If you have a client and server talking to one another, and you recompile one having made only small internal changes, it should still inter-work with the original client. Something like that perhaps? Clearly this isn't yet a precise statement and you might want to make it so. And so on. Do you see what I mean? On the question of "I think it would be really useful if there was a way to send type details with a more complete serialization of the construction", I don't understand well enough. I tried (perhaps inadequately) to describe a design in which type security was guaranteed without sending type representations or fingerprints at all. Of course, some higher-level guarantees might be gained by sending type reps, but that would be up to a client library built on top of the facilities GHC provides. Are you asking for any GHC support here, or simply saying something about what a client library might or might not chose to do? Sorry to be dense. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 20:30:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 20:30:28 -0000 Subject: [GHC] #9560: "Illegal equational constraint" that might not be the users fault In-Reply-To: <047.4b32a75218bc7c94ef91d174dc35c083@haskell.org> References: <047.4b32a75218bc7c94ef91d174dc35c083@haskell.org> Message-ID: <062.a7f80e562de797dabe23c4e7827ce79f@haskell.org> #9560: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Double submission: #9558. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 20:30:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 20:30:41 -0000 Subject: [GHC] #9559: "Illegal equational constraint" that might not be the users fault In-Reply-To: <047.fdb9c54a06f2e7b9f635fd313e0cea86@haskell.org> References: <047.fdb9c54a06f2e7b9f635fd313e0cea86@haskell.org> Message-ID: <062.b4996fb484d93811d0ee33752f340557@haskell.org> #9559: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Double submission: #9558. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 20:44:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 20:44:43 -0000 Subject: [GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. In-Reply-To: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> References: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> Message-ID: <058.6f7323ce534ca4ed1475cfb013be9ba0@haskell.org> #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: type family, Resolution: | ambiguity check Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I tried with 7.0. Yes, if you omit the type signature for `te4`, GHC 7.0 will infer the one you give. But if you write in that type signature, 7.0 will reject the program with the same error, which is hardly satisfactory. No, GHC 7.0 did not "guess" some type-variable equalities that would solve the constraints. I have absolutely no idea how to do this in general, and GHC has never attempted to do so. It's just that 7.0 allowed you to infer a type that, if you wrote it as the signature, would be rejected. GHC 7.4 etc don't do that, which on the whole is a good thing. While I could reverse that decision, it doesn't seem like the right way to solve the problem. The right way is to get GHC to make right instantiations, along the lines you mention. How can we do that? Usually by supplying some type signatures. I don't understand the code well enough, but can you do this? * write the type sig for `te4`, using a `forall` so that the type variables scope over the body, * give some type signatures in the body so that the type variable equalities you want are forced Alternatively, do you have any other suggestions for how to guide GHC to make the right choices during inference? Especially if injectivity won't do it. Mind you, injectivity might do it if you used an auxiliary family for the particular `repr` you care about. Eg {{{ type family Arr r a b :: * type instance Arr MyRepr a b = MyArr a b -- Arr is not injective type family MyArr a b :: * | result -> a b -- MyArr is injective }}} Might that work? I'm sure you will have other creative ideas. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 21:28:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 21:28:28 -0000 Subject: [GHC] #9603: getArgs path transformation is broken on Windows In-Reply-To: <045.e61ab36b85802c1081d92cfe8af2fe04@haskell.org> References: <045.e61ab36b85802c1081d92cfe8af2fe04@haskell.org> Message-ID: <060.998a5f8359e9c4b555309f1247af2ece@haskell.org> #9603: getArgs path transformation is broken on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): This turns out to be an issue with the old mingw gcc that is bundled with GHC in the ghc-tarballs repository. A simple C file printing it arguments prints a mangled string when compiled with the bundled gcc, but works fine when using the relatively up-to-date system gcc version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 21:33:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 21:33:15 -0000 Subject: [GHC] #9604: Python test runner assumes native Python on Windows Message-ID: <045.eaed88e165e20cf0975a545fb150c6a7@haskell.org> #9604: Python test runner assumes native Python on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- runtests.py assumes that ctypes.windll is always available when running on Windows, but that is in fact only available when using a native Windows Python, but not the mingw/msys Python. The code causes a crash over a trivial issue of setting the terminal to UTF-8 mode. See attached patch for a fix. (The second patch is a cleanup.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 21:34:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 21:34:05 -0000 Subject: [GHC] #9604: Python test runner assumes native Python on Windows In-Reply-To: <045.eaed88e165e20cf0975a545fb150c6a7@haskell.org> References: <045.eaed88e165e20cf0975a545fb150c6a7@haskell.org> Message-ID: <060.fda76e6dc6139196b1cd5fbc20a91690@haskell.org> #9604: Python test runner assumes native Python on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 21:35:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 21:35:39 -0000 Subject: [GHC] #9574: GHC Panic: No Skolem Info In-Reply-To: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> References: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> Message-ID: <060.3c9f44755a5098d8e75d27b0dcf38279@haskell.org> #9574: GHC Panic: No Skolem Info -------------------------------------+------------------------------------- Reporter: ian_mi | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => infoneeded Comment: @ian_mi: can you provide a testcase, even if it's huge or depends on hackage libraries? I can try to reduce it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 22:01:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 22:01:56 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs In-Reply-To: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> References: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> Message-ID: <066.39fb202a5631985fa672dde128b5b8d1@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: InstanceSigs (Type checker) | TypeFamilies Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by andreas.abel): Relevant snippet: Checking InstanceSigs uses eqType. https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcInstDcls.lhs {{{#!hs -- Check that any type signatures have exactly the right type check_inst_sig hs_ty@(L loc _) = setSrcSpan loc $ do { sig_ty <- tcHsSigType (FunSigCtxt sel_name) hs_ty ; inst_sigs <- xoptM Opt_InstanceSigs ; if inst_sigs then unless (sig_ty `eqType` local_meth_ty) (badInstSigErr sel_name local_meth_ty) else addErrTc (misplacedInstSig sel_name hs_ty) ; return sig_ty } }}} Last commit: https://github.com/ghc/ghc/commit/7fa2ce2043e2faed2b2b545ba5c1c9958954800a According to the documentation, eqType only takes type synonyms into account (not type families). https://github.com/ghc/ghc/blob/master/compiler/types/Type.lhs {{{#!hs eqType :: Type -> Type -> Bool -- ^ Type equality on source types. Does not look through @newtypes@ or -- 'PredType's, but it does look through type synonyms. -- Watch out for horrible hack: See Note [Comparison with OpenTypeKind] eqType t1 t2 = isEqual $ cmpType t1 t2 cmpType :: Type -> Type -> Ordering -- Watch out for horrible hack: See Note [Comparison with OpenTypeKind] cmpType t1 t2 = cmpTypeX rn_env t1 t2 where rn_env = mkRnEnv2 (mkInScopeSet (tyVarsOfType t1 `unionVarSet` tyVarsOfType t2)) cmpTypeX :: RnEnv2 -> Type -> Type -> Ordering -- Main workhorse cmpTypeX env t1 t2 | Just t1' <- coreView t1 = cmpTypeX env t1' t2 | Just t2' <- coreView t2 = cmpTypeX env t1 t2' -- We expand predicate types, because in Core-land we have -- lots of definitions like -- fOrdBool :: Ord Bool -- fOrdBool = D:Ord .. .. .. -- So the RHS has a data type cmpTypeX env (TyVarTy tv1) (TyVarTy tv2) = rnOccL env tv1 `compare` rnOccR env tv2 -- plus congruences... }}} Where to find the type equality check that honors type family instances? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 22:06:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 22:06:39 -0000 Subject: [GHC] #9502: mapAccumL does not participate in foldr/build fusion In-Reply-To: <045.004d5a2aa80154a27f3198a7a0d1aca1@haskell.org> References: <045.004d5a2aa80154a27f3198a7a0d1aca1@haskell.org> Message-ID: <060.13c78ce9fb25186902f8d78e9e04b283@haskell.org> #9502: mapAccumL does not participate in foldr/build fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 22:12:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 22:12:23 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs In-Reply-To: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> References: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> Message-ID: <066.8afa18f452265a8d902e7d8e74b7e50e@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: InstanceSigs (Type checker) | TypeFamilies Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): It's not just type families. You'd also expect that re-ordering the constraints in a qualified context would make no difference: {{{ expected: (Eq a, Num a) => a -> a actual: (Num a, Eq a) => a -> a }}} I think the Right Thing is to use `TcUnify.tcSubType`, twice. It checks that t1 is more polymorphic than t2; so you can call it with t1,t2 and with t2,t1. It instantiates one type, skolemises the other, and does full constraint solving. Look at other calls to `tcSubType` to see how it is used. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 22:14:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 22:14:28 -0000 Subject: [GHC] #9605: Misleading error message with forgotten "do" Message-ID: <043.4d0a36fa55a61f7a0e16739341de4daf@haskell.org> #9605: Misleading error message with forgotten "do" -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In the following (simplified) code, I forgot to add the do keyword, when doing some refactoring. This caused GHC to give a strange error message that said approximately "The function F is applied to two arguments, but its type T has only two"... which is odd! {{{#!hs import Control.Monad.RWS ( evalRWS, RWS ) import Control.Monad.Writer.Class ( tell ) main = print $ evalRWS (go 1) () () go :: Int -> RWS () [String] () () go i = --Oops, forgot a do here return (show i) >>= (\l -> tell [l]) -- go $ i + 1 go i }}} Strangely, replacing the "go i" line with the commented-out line above it gives a sensible error message, the "Possible cause: `\l -> tell [l]' is applied to too many arguments" message, which is correct, and would've pointed me straight to the problem. The invalid error message, which appears to be the same using GHC 7.6.3 and 7.8.3, is: {{{ NFA.hs:8:25: Couldn't match type ?String -> Control.Monad.Trans.RWS.Lazy.RWST () [String] () Data.Functor.Identity.Identity ()? with ?()? Expected type: Int -> String -> Control.Monad.Trans.RWS.Lazy.RWST () [String] () Data.Functor.Identity.Identity () Actual type: Int -> () The function ?\ l -> tell [l]? is applied to two arguments, but its type ?(Int -> RWS () [String] () ()) -> Int -> ()? has only two In the second argument of ?(>>=)?, namely ?(\ l -> tell [l]) go i? In the expression: return (show i) >>= (\ l -> tell [l]) go i }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 22:24:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 22:24:56 -0000 Subject: [GHC] #9606: Improve outdated ghc-pkg cache warning Message-ID: <042.9c58fbc29cb9829bc37b485448322dc0@haskell.org> #9606: Improve outdated ghc-pkg cache warning -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: ghc-pkg | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Sometimes you get this: {{{ WARNING: cache is out of date: /home/user/.ghc/x86_64-linux-7.8.3/package.conf.d/package.cache. Use 'ghc-pkg recache' to fix }}} The warning is correct but a bit confusing, because running `ghc-pkg recache` does nothing here: It will by default update your global package DB, and the DB the warning is about will still be out of date. This seems to have frustrated others as well: https://gist.github.com/mcandre/5789498 I suggest we make the message more clear: `You might have to pass --user to update this cache file`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 23:19:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 23:19:49 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.02574d1ca0a5f72787b12f1d0cebfc0d@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Replying to [comment:9 rwbarton]: Thank you for your feedback. I've updated the wiki page. Re anticipating setting for all possible systems, how would it hurt, if i386 GHC, whenever if detected that TARGET /= HOST, always kept setting something like {{{ --ghc-option="-optc-m32" --ghc-option="-opta-m32" --ghc-option="-optl-m32" --ld-option="-melf_i386" }}} It's not x86_64 specific, at least, isn't it? As a default, it's less clean but more effective than the optimistic empty list of options. Thank you for the {{{lib/settings}}} suggestion. I will try that and report here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 17 23:59:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Sep 2014 23:59:42 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.ab7cf8df549130d677c30a32523ff3f8@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch Comment: I think that should take care of the problems I was seeing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 00:08:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 00:08:44 -0000 Subject: [GHC] #7353: Make system IO interruptible on Windows In-Reply-To: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> References: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> Message-ID: <063.705c6d8e3a3978e411c25e6332e65324@haskell.org> #7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.1 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by martin-bailey): * cc: hvr, ekmett (added) Comment: Is anyone currently working on an IO manager for Windows? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 01:55:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 01:55:00 -0000 Subject: [GHC] #8097: internal error: getMBlock: mmap: Operation not permitted In-Reply-To: <049.1374c35c9fb9ae4822815a0497de3a42@haskell.org> References: <049.1374c35c9fb9ae4822815a0497de3a42@haskell.org> Message-ID: <064.7c7457ecc4cb7844fb2886211e6325dc@haskell.org> #8097: internal error: getMBlock: mmap: Operation not permitted ----------------------------------------+--------------------------- Reporter: singpolyma | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+--------------------------- Changes (by rwbarton): * status: infoneeded => closed * resolution: => duplicate Comment: So SirReal's issue is the one fixed in #7500; hard to tell about singpolyma's but it seems highly likely, so I'm just going to close this. Please reopen if you encounter the same error in 7.6 or newer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 04:28:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 04:28:53 -0000 Subject: [GHC] #9574: GHC Panic: No Skolem Info In-Reply-To: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> References: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> Message-ID: <060.f32223986d495d26d86308f6f531eef9@haskell.org> #9574: GHC Panic: No Skolem Info -------------------------------------+------------------------------------- Reporter: ian_mi | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ian_mi): Sure. I've been trying to reduce it myself but it's been somewhat tricky. I will put together an unreduced example instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 05:14:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 05:14:55 -0000 Subject: [GHC] #9607: Type checking regression between GHC 7.6 and 7.8 Message-ID: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> #9607: Type checking regression between GHC 7.6 and 7.8 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Jason McCarty [http://www.haskell.org/pipermail/haskell- cafe/2014-September/116076.html reported on Haskell-cafe] that this code used to work with GHC 7.6 but in GHC 7.8 it requires `AllowAmbiguousTypes`: {{{#!hs -- The code below is simplified from code that computes a tensor product of -- a tensor with an identity matrix whose size is determined from the -- shapes of the input and output tensors. {-# LANGUAGE DataKinds, KindSignatures, TypeFamilies, TypeOperators #-} --{-# LANGUAGE AllowAmbiguousTypes #-} module Tensors where import GHC.TypeLits type family (as :: [Nat]) ++ (bs :: [Nat]) :: [Nat] type instance '[] ++ bs = bs type instance (a ': as) ++ bs = a ': (as ++ bs) data Tensor (s :: [Nat]) = Tensor -- content elided -- apparently GHC reduces (++) enough to see that n is determined leftUnit :: Tensor s -> Tensor ('[n, n] ++ s) leftUnit Tensor = Tensor -- accepted in 7.6, not accepted in 7.8 without AllowAmbiguousTypes rightUnit :: Tensor s -> Tensor (s ++ '[n, n]) rightUnit Tensor = Tensor -- also accepted without AllowAmbiguousTypes outsideUnit :: Tensor s -> Tensor ('[n] ++ s ++ '[n]) outsideUnit Tensor = Tensor useleftUnit :: Tensor '[1,1,2] useleftUnit = leftUnit Tensor -- type of Tensor is inferred userightUnit :: Tensor '[1,2,2] userightUnit = rightUnit (Tensor :: Tensor '[1]) -- type must be provided }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 05:59:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 05:59:23 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.c78ebcbb5e423d4b5f74d8f741062bd5@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): A nice syntax proposal showed up on Haskell-cafe. The idea is to allow user to actually introduce a variable that names the result: {{{#!hs type family Id a :: (result :: *) | result -> a where type family F a b c :: (d :: *) | d -> a b c type family G a b c :: (foo :: *) | foo-> a b where type family Plus a b :: (sum :: Nat) | sum a -> b, sum b -> a where type family H a b c :: (xyz :: *) | xyz a -> b c, xyz b -> a c }}} No new keywords, so we get full backwards compatibility. I'm only wondering how this would interact with kind signatures for the result, which we allow now. Above I assumed that if a programmer wants to name the result she must supply a kind annotation. This might be a bit inconvenient. On the other hand I think that the range of possible names for type variables and kinds is disjoint, so we may actually guess whether the user means the kind of the result or its name by looking whether the identifier is capitalized. So we could just write: {{{#!hs type family Id a :: result | result -> a where type family F a b c :: d | d -> a b c type family G a b c :: foo | foo-> a b where type family Plus a b :: sum | sum a -> b, sum b -> a where type family H a b c :: xyz | xyz a -> b c, xyz b -> a c }}} The only caveat I see is that user might accidentally write `type family Plus a b :: nat` instead of `type family Plus a b :: Nat` and then get some weird compilation errors if the kind signature was essential to make the code compile. Still, I like this proposal best of all made so far. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 06:15:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 06:15:35 -0000 Subject: [GHC] #9592: Add link to wiki index in the ticket view on Trac In-Reply-To: <048.6987748ece46df1b7890c87d4a4593a4@haskell.org> References: <048.6987748ece46df1b7890c87d4a4593a4@haskell.org> Message-ID: <063.8b628d0e363b069dbc2c8c2d048dd66f@haskell.org> #9592: Add link to wiki index in the ticket view on Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: hvr Type: feature | Status: closed request | Milestone: Priority: normal | Version: Component: Trac & Git | Keywords: Resolution: worksforme | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => worksforme Comment: I just realized there is a link to the Index in the side panel. This is perfectly sufficient for my needs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 07:57:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 07:57:23 -0000 Subject: [GHC] #9287: changed dependency generation In-Reply-To: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> References: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> Message-ID: <060.0fd8c1499cdb47b0c96c66de33db708c@haskell.org> #9287: changed dependency generation -------------------------------------+------------------------------------- Reporter: maeder | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 08:22:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 08:22:48 -0000 Subject: [GHC] #9606: Improve outdated ghc-pkg cache warning In-Reply-To: <042.9c58fbc29cb9829bc37b485448322dc0@haskell.org> References: <042.9c58fbc29cb9829bc37b485448322dc0@haskell.org> Message-ID: <057.624e7d0ffb69c330696fa391df25ffd3@haskell.org> #9606: Improve outdated ghc-pkg cache warning -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: ghc-pkg | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Sounds like a good idea to me. Would someone like to create and validate a patch? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 11:06:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 11:06:39 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.722b08d9f070284484ea7548dca2488c@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > More details to follow. I've created this ticket to be able to refer to > from related preparatory commits. New description: More details to follow. I've created this ticket to be able to refer to from related preparatory commits. In a nutshell the goal (more or less) of this proposal is to be able to compile code like the following w/o errors (due to conflicting definitions): {{{#!hs module XPrelude (module X) where import Data.Foldable as X import Data.Traversable as X import Data.List as X import Control.Monad as X import Prelude as X }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 12:24:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 12:24:01 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.bb71b150d8957838072e7d007bef5a20@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by rwbarton): That reads very oddly to me, but how about...? {{{ type family Id a = result | result -> a where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 12:34:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 12:34:15 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.be0754d179817d44e9ee4b04e7023f4a@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:69 rwbarton]: > That reads very oddly to me, but how about...? > {{{ > type family Id a = result | result -> a where > }}} You mean that the `:: result` syntax reads oddly? It is already supported by GHC and the nice thing about this proposal is that we can piggyback on the syntax we already have. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 12:51:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 12:51:26 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.69a0678cc9955d541cd80fbcf2dfa0b0@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by simonpj): The difficulty is that when you say {{{ type family F (a::*) :: * }}} you expect `a` to be a ''type'' variable and `*` to be a ''kind''. So if you say {{{ type family F (a::*) :: (b :: *) }}} it looks as though `b` is a ''kind'' variable, and `*` is a ''sort''. That's why Reid wants to use `=` rather than `::`, and he is right. It's reasonable to have either of these {{{ type family F a :: * type family F a = (b :: *) }}} but not {{{ type family F a :: (b :: *) }}} The merit of the "= blah" notation is that it allows us to give a name to the result, rather than use a magic name. I think it's probably just about worth the syntactic cost. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 14:47:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 14:47:37 -0000 Subject: [GHC] #9608: Type level as-patterns Message-ID: <046.b5996effd54422c4b764b9e3de90a562@haskell.org> #9608: Type level as-patterns -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hello! I would love to see type level as-patterns in Haskell. They would be very helpfull when writing complex type families. Here is a good example: {{{ #!haskell type family XOut m1 m2 where XOut (ValueS vbase vs) (MonadCtx2Dummy' m2 s2 env set m s) = MonadCtx2Dummy' m2 s2 (XEnv env (ValueS vbase vs)) (XSet set (ValueS vbase vs)) m (XSafety s (ValueS vbase vs)) }}} could then be written as: {{{ #!haskell type family XOut m1 m2 where XOut a@(ValueS vbase vs) (MonadCtx2Dummy' m2 s2 env set m s) = MonadCtx2Dummy' m2 s2 (XEnv env a) (XSet set a) m (XSafety s a) }}} which is much cleaner, less verbose and lot safer then the first one. (Safer in terms of accidental typos when refactoring etc). Cheers, Wojciech -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 14:48:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 14:48:11 -0000 Subject: [GHC] #9608: Type level as-patterns In-Reply-To: <046.b5996effd54422c4b764b9e3de90a562@haskell.org> References: <046.b5996effd54422c4b764b9e3de90a562@haskell.org> Message-ID: <061.29f69fd76f586b5b074a00679e6d0bf0@haskell.org> #9608: Type level as-patterns -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hello! I would love to see type level as-patterns in Haskell. They would > be very helpfull when writing complex type families. Here is a good > example: > > {{{ > #!haskell > type family XOut m1 m2 where > XOut (ValueS vbase vs) (MonadCtx2Dummy' m2 s2 env set m s) = > MonadCtx2Dummy' m2 s2 (XEnv env (ValueS vbase vs)) (XSet set (ValueS > vbase vs)) m (XSafety s (ValueS vbase vs)) > }}} > > could then be written as: > > {{{ > #!haskell > type family XOut m1 m2 where > XOut a@(ValueS vbase vs) (MonadCtx2Dummy' m2 s2 env set m s) = > MonadCtx2Dummy' m2 s2 (XEnv env a) (XSet set a) m (XSafety s a) > }}} > > which is much cleaner, less verbose and lot safer then the first one. > (Safer in terms of accidental typos when refactoring etc). > > Cheers, > Wojciech New description: Hello! I would love to see type level as-patterns in Haskell. They would be very helpfull when writing complex type families. Here is a good example: {{{ #!haskell type family XOut m1 m2 where XOut (ValueS vbase vs) (MonadCtx2Dummy' m2 s2 env set m s) = MonadCtx2Dummy' m2 s2 (XEnv env (ValueS vbase vs)) (XSet set (ValueS vbase vs)) m (XSafety s (ValueS vbase vs)) }}} could then be written as: {{{ #!haskell type family XOut m1 m2 where XOut a@(ValueS vbase vs) (MonadCtx2Dummy' m2 s2 env set m s) = MonadCtx2Dummy' m2 s2 (XEnv env a) (XSet set a) m (XSafety s a) }}} which is much cleaner, less verbose and lot safer than the first one. (Safer in terms of accidental typos when refactoring etc). Cheers, Wojciech -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 14:49:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 14:49:27 -0000 Subject: [GHC] #9608: Type level as-patterns In-Reply-To: <046.b5996effd54422c4b764b9e3de90a562@haskell.org> References: <046.b5996effd54422c4b764b9e3de90a562@haskell.org> Message-ID: <061.41f538414baa63c31bf02da9dcd345e6@haskell.org> #9608: Type level as-patterns -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for it. Not too hard, if someone wants to undertake it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 15:26:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 15:26:56 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.0adab0fc1ad5183506fd83eb07ae22fd@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): Ah, of course. I was thinking about this problem earlier but then I somehow convinced myself that this will not be an issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 15:37:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 15:37:23 -0000 Subject: [GHC] #9607: Type checking regression between GHC 7.6 and 7.8 In-Reply-To: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> References: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> Message-ID: <063.f8dfb21371f3c0c9f54512868f39e49d@haskell.org> #9607: Type checking regression between GHC 7.6 and 7.8 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Indeed, and there is a good reason for that: when you call `rightUnit`, its unclear how to instantiate `n`; its type is indeed ambiguous. For example, if you write this {{{ rightUnit1 :: Tensor s -> Tensor (s ++ '[n, n]) ru1 = rightUnit }}} you might expect it to be accepted. After all, that ''is'' the type of `rightUnit`! But it's rejected thus: {{{ T9607.hs:34:7: Couldn't match type ?s ++ '[n0, n0]? with ?s ++ '[n, n]? NB: ?++? is a type function, and may not be injective The type variable ?n0? is ambiguous Expected type: Tensor s -> Tensor (s ++ '[n, n]) Actual type: Tensor s -> Tensor (s ++ '[n0, n0]) Relevant bindings include ru1 :: Tensor s -> Tensor (s ++ '[n, n]) (bound at T9607.hs:34:1) In the expression: rightUnit In an equation for ?ru1?: ru1 = rightUnit }}} This perplexing behaviour is ruled out by the default of `-XNoAllowAmbiguousTypes`. However your example is useful because it shows an example where a function with an ambiguous type can nevertheless be called in an entirely unambiguous way. The call in `userightUnit` instantiates the type of `rightUnit` with (say) `s = ss` and `n = nn`. Now we get the following constraints: {{{ Tensor ss ~ Tensor [1] -- From the argument of rightUnit Tensor (ss ++ [nn, nn]) ~ Tensor [1,2,2] -- From the result of rightUnit }}} solving the first gives `ss ~ [1]`. Substituting in the second gives {{{ [1] ++ [nn,nn] ~ [1,2,2] }}} Now use the equations for `++` and you can see this is readily solved by `nn ~ 2`. In short, ''some'' calls to `rightUnit` will give rise to ambiguity, but not all. It's not clear what "better" behaviour might be. One thing I can think of is this: * Allow ambiguous user-written type signatures * But do not infer ambiguous types I.e. if you want a function to get an ambiguous type you must say so. See also #9587 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 15:43:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 15:43:16 -0000 Subject: [GHC] #9607: Type checking regression between GHC 7.6 and 7.8 In-Reply-To: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> References: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> Message-ID: <063.3ec7d9874da03e43b1f3ff7e3fc05112@haskell.org> #9607: Type checking regression between GHC 7.6 and 7.8 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => invalid Comment: So this is essentially a feature, not a bug? In that case I'll close this report as 'invalid'. I was puzzled because it used to work with 7.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 15:43:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 15:43:41 -0000 Subject: [GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. In-Reply-To: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> References: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> Message-ID: <058.5272540aea3b8bc492ae37f9e73de306@haskell.org> #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: type family, Resolution: | ambiguity check Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: #9607 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #9607 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 15:59:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 15:59:39 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs In-Reply-To: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> References: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> Message-ID: <066.6f42cdba7e3027358fe0a1fd6be3dbbc@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: InstanceSigs (Type checker) | TypeFamilies Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by andreas.abel): Thanks, Simon, I got quite far with your help: {{{#!hs -- Check that any type signatures have exactly the right type check_inst_sig hs_ty@(L loc _) = setSrcSpan loc $ do { let userTypeCtxt = FunSigCtxt sel_name ; sig_ty <- tcHsSigType userTypeCtxt hs_ty ; inst_sigs <- xoptM Opt_InstanceSigs ; if inst_sigs then do -- Check that type provided in the type signature -- is both a sub- and a super-type of the type -- originating from the method signature in the class. -- As a consequence, the types are equal, and we can discard -- the coercions. (Keep fingers crossed.) let ctOrigin = AmbigOrigin userTypeCtxt void $ tcSubType ctOrigin userTypeCtxt sig_ty local_meth_ty (errMsgs, result) <- tryTcErrs $ tcSubType ctOrigin userTypeCtxt local_meth_ty sig_ty -- In case the provided type is more general than the expected -- type, we give a custom error message. -- Really, providing a method implementation of a more general type -- OUGHT to be allowed, so the error coming from a failure of subtyping -- is confusing. -- However, in the latter case we cannot simply discard the coercion... case result of Just _coercion -> return () Nothing -> badInstSigErr sel_name local_meth_ty -- unless (sig_ty `eqType` local_meth_ty) -- (badInstSigErr sel_name local_meth_ty) else addErrTc (misplacedInstSig sel_name hs_ty) ; return sig_ty } }}} My test case is now accepted. I am also happy with the error message if the instance signature is too specific (first tcSubType check). I tried to give a better error message than the one thrown by tcSubTyp if the instance signature is more general than the method signature coming from the class. However, it does not seem to work, it is as if the tryTcErrs would not catch the errors thrown by tcSubType. This is unlikely however, my suspicion is that tcSubType just generates constraints which it hopes to solve later and then fails. Anyway, I need some advice how to catch errors or replace errors by other ones... For illustration, here is the case that the user gives a too general instance signature and receives a misleading error message: {{{#!hs {-# LANGUAGE InstanceSigs, TypeFamilies #-} module Fail where class C a where type T a m :: T a instance C Int where type T Int = String -- The following type signature for m is currently rejected, -- as it is too general. m :: Show a => [a] m = [] }}} {{{ Couldn't match type ?[Char]? with ?forall a. Show a => [a]? Expected type: forall a. Show a => [a] Actual type: T Int In the instance declaration for ?C Int? }}} The error is confusing, at least because the roles of expected and actual types are reversed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 16:11:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 16:11:50 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs In-Reply-To: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> References: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> Message-ID: <066.e2f871ecbfde71626f8bae9791814b9e@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: InstanceSigs (Type checker) | TypeFamilies Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by andreas.abel): P.S.: Patch is on github, see https://github.com/andreasabel/ghc/commit/b2975ed0531493429c3f844e6d243fb1818c895d -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 16:36:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 16:36:09 -0000 Subject: [GHC] #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' In-Reply-To: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> References: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> Message-ID: <064.86e32b9f7e07fb8f54af3adca156671d@haskell.org> #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' -------------------------------------+------------------------------------- Reporter: jpmasseria | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jpmasseria): Success! I manually created the symlinks that `libc6-dev` creates between `/usr/lib/` to `/lib` as relative links as described in the StackOverflow posting you provided [http://stackoverflow.com/questions/13626726/an- error-building-qt-libraries-for-the-raspberry-pi] and the build completed. Here are the symlinks I created: {{{ johnma at aspire-ubuntu:~$ ls -l rpi-toolchain/rootfs/usr/lib/arm-linux- gnueabihf/ | grep "../.." lrwxrwxrwx 1 johnma johnma 44 Sep 17 19:07 libanl.so -> ../../../lib /arm-linux-gnueabihf/libanl.so.1 lrwxrwxrwx 1 johnma johnma 53 Sep 17 19:08 libBrokenLocale.so -> ../../../lib/arm-linux-gnueabihf/libBrokenLocale.so.1 lrwxrwxrwx 1 johnma johnma 45 Sep 17 19:08 libcidn.so -> ../../../lib/arm-linux-gnueabihf/libcidn.so.1 lrwxrwxrwx 1 johnma johnma 46 Sep 17 19:08 libcrypt.so -> ../../../lib/arm-linux-gnueabihf/libcrypt.so.1 lrwxrwxrwx 1 johnma johnma 43 Sep 17 18:50 libdl.so -> ../../../lib /arm-linux-gnueabihf/libdl.so.2 lrwxrwxrwx 1 johnma johnma 42 Sep 17 19:08 libm.so -> ../../../lib /arm-linux-gnueabihf/libm.so.6 lrwxrwxrwx 1 johnma johnma 44 Sep 17 19:08 libnsl.so -> ../../../lib /arm-linux-gnueabihf/libnsl.so.1 lrwxrwxrwx 1 johnma johnma 51 Sep 17 19:08 libnss_compat.so -> ../../../lib/arm-linux-gnueabihf/libnss_compat.so.2 lrwxrwxrwx 1 johnma johnma 48 Sep 17 19:08 libnss_dns.so -> ../../../lib/arm-linux-gnueabihf/libnss_dns.so.2 lrwxrwxrwx 1 johnma johnma 50 Sep 17 19:08 libnss_files.so -> ../../../lib/arm-linux-gnueabihf/libnss_files.so.2 lrwxrwxrwx 1 johnma johnma 51 Sep 17 19:08 libnss_hesiod.so -> ../../../lib/arm-linux-gnueabihf/libnss_hesiod.so.2 lrwxrwxrwx 1 johnma johnma 52 Sep 17 19:08 libnss_nisplus.so -> ../../../lib/arm-linux-gnueabihf/libnss_nisplus.so.2 lrwxrwxrwx 1 johnma johnma 48 Sep 17 19:08 libnss_nis.so -> ../../../lib/arm-linux-gnueabihf/libnss_nis.so.2 lrwxrwxrwx 1 johnma johnma 47 Sep 17 19:08 libresolv.so -> ../../../lib/arm-linux-gnueabihf/libresolv.so.2 lrwxrwxrwx 1 johnma johnma 43 Sep 17 19:08 librt.so -> ../../../lib /arm-linux-gnueabihf/librt.so.1 lrwxrwxrwx 1 johnma johnma 50 Sep 17 19:08 libthread_db.so -> ../../../lib/arm-linux-gnueabihf/libthread_db.so.1 lrwxrwxrwx 1 johnma johnma 45 Sep 17 19:08 libutil.so -> ../../../lib/arm-linux-gnueabihf/libutil.so.1 johnma at aspire-ubuntu:~$ }}} On my system the links did not exist at all. I had copied the `/lib` and `/usr/lib` from my target machine to my build machine using `rsync`. It is possible that my target machine did not have `libc6-dev` installed. My target machine is down right now so I can't tell that for sure. However, bottom line, for me to build a stage1 cross-compiler for a Raspberry Pi I had to create the relative symlinks shown above. I also had to create a short script to call `gcc` using `--sysroot` pointing to my local sysroot with my target `/lib` and `/usr/lib` directories as follows where `arm-linux-gnuabihf-gcc` is the cross-compiler from [https://github.com/raspberrypi/tools] installed on my build machine: {{{ johnma at aspire-ubuntu:~$ cat mygcc #!/bin/bash arm-linux-gnueabihf-gcc --sysroot=/home/johnma/rpi-toolchain/rootfs $@ johnma at aspire-ubuntu:~$ }}} And then used this `./configure` command: {{{ ./configure --target=arm-linux-gnueabihf --enable-unregisterised --with- gcc=/home/johnma/mygcc --with-nm=/usr/bin/nm }}} I tested my build as follows: {{{ johnma at aspire-ubuntu:~$ ./ghc/inplace/bin/ghc-stage1 haq.hs [1 of 1] Compiling Main ( haq.hs, haq.o ) Linking haq ... johnma at aspire-ubuntu:~$ johnma at aspire-ubuntu:~$ file haq haq: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, Buil dID[sha1]=26c431c1e98551502c244089c9028ce7e83b7a30, not stripped johnma at aspire-ubuntu:~$ johnma at aspire-ubuntu:~$ cat haq.hs -- -- Copyright (c) 2006 Don Stewart - http://www.cse.unsw.edu.au/~dons/ -- GPL version 2 or later (see http://www.gnu.org/copyleft/gpl.html) -- import System.Environment -- | 'main' runs the main program main :: IO () main = getArgs >>= print . haqify . head haqify s = "Haq! " ++ s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 16:50:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 16:50:45 -0000 Subject: [GHC] #9609: GHCi gives overly specific error message for unknown constructor Message-ID: <045.9950188f6ab93cc71f8af2cda0ae9fed@haskell.org> #9609: GHCi gives overly specific error message for unknown constructor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- What happens: {{{ Prelude> :i Fish Top level: Not in scope: data constructor ?Fish? }}} This is potentially confusing because `:i` can be used for type constructors and classes, as well as data constructors. What I think should happen: {{{ Prelude> :i Fish Top level: Not in scope: constructor or class ?Fish? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 17:01:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 17:01:36 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs In-Reply-To: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> References: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> Message-ID: <066.312ec26644c2bfa94a30546dc16a983a@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: patch Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: InstanceSigs (Type checker) | TypeFamilies Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 17:10:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 17:10:25 -0000 Subject: [GHC] #9609: GHCi gives overly specific error message for unknown constructor In-Reply-To: <045.9950188f6ab93cc71f8af2cda0ae9fed@haskell.org> References: <045.9950188f6ab93cc71f8af2cda0ae9fed@haskell.org> Message-ID: <060.854eef4352e75fd64607ad215c97619b@haskell.org> #9609: GHCi gives overly specific error message for unknown constructor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) * version: 7.8.2 => 7.8.3 * component: Compiler => GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 19:02:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 19:02:31 -0000 Subject: [GHC] #9607: Type checking regression between GHC 7.6 and 7.8 In-Reply-To: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> References: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> Message-ID: <063.268d00967615027401304cc4075902b4@haskell.org> #9607: Type checking regression between GHC 7.6 and 7.8 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jmccarty): Indeed, I'm guessing it was a bug that 7.6 accepted my program. I would argue that the type is not per se ambiguous, GHC just can't see it. `leftUnit` is precisely as ambiguous as `rightUnit`, but `leftUnit` is considered unambiguous (I think) because the type family application simplifies, making the signature `Tensor s -> Tensor (n ': n ': s)`, and I guess `':` is accepted as injective. In principle, if the argument and return types of rightUnit are instantiated to some type, then `n` can be instantiated to a unique type (but GHC would have to invert `(s ++)` to determine it!). I don't really understand the ambiguity check, but I think GHC wants to check that `(s ++ '[n0, n0]) ~ (s ++ '[n, n])` implies `n0 ~ n`? This is provably true, but I certainly don't expect GHC to construct the inductive proof of this fact. I was hoping the type family injectivity proposal would allow declaring such a fact (but again, I don't know that GHC could verify it). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 20:31:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 20:31:36 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.1d00b759c443807b0d7d1593baa316bd@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by dfeuer): I think if you're doing this, it would make sense to generalize these too: {{{#!hs null :: (Foldable f) => f a -> Bool null = foldr (const True) False length :: (Foldable f) => f a -> Int length = foldl' (\k _ -> k + 1) 0 --and even though it's a very strange thing already genericLength :: (Foldable f, Num n) => f a -> n genericLength = foldr (\_ k -> 1 + k) 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 20:54:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 20:54:56 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.3846c5509b55b98d585abb762b8ebde7@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:4 dfeuer]: rwbarton points out that there are optimized versions of these for various things, and that most containers use `size` instead of `length`. Therefore, I would propose instead adding `size` and `null` to the `Foldable` class, with default definitions as above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 21:13:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 21:13:12 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.6156145456ad6c4711c6fffd343576cf@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"8b9083655f34120b47fe407123272e0687e0bd60/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8b9083655f34120b47fe407123272e0687e0bd60" Move (=<<) to GHC.Base This allows GHC.Stack to avoid importing Control.Monad, and is preparatory work for implementing #9586 Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D221 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 21:13:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 21:13:12 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.63b824a87c9359eb1157be07061efca4@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"a94dc4c3067c6a0925e2e39f35ef0930771535f1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a94dc4c3067c6a0925e2e39f35ef0930771535f1" Move Applicative/MonadPlus into GHC.Base This is necessary in order to invert the import-dependency between Data.Foldable and Control.Monad (for addressing #9586) This also updates the `binary` submodule to qualify a GHC.Base import Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D223 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 21:13:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 21:13:12 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.75623bc5ce32e63714ec719f1f1f681b@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"eae19112462fe77a3f1298bff12b409b205a581d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="eae19112462fe77a3f1298bff12b409b205a581d" Move `when` to GHC.Base This allows several modules to avoid importing Control.Monad and thus break import cycles that manifest themselves when implementing #9586 Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D222 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 21:13:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 21:13:12 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.0e8f3fc600e306ce47179889ac39ba38@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"af22696b8f6d8b677c33f70537a5999ad94266cd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="af22696b8f6d8b677c33f70537a5999ad94266cd" Invert module-dep between Control.Monad and Data.Foldable This is the last preparation needed before generalizing entities in Control.Monad conflicting with those from Data.Foldable (re #9586) Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D225 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 21:13:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 21:13:12 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.7734d8503c60f6e6cb45b2b84e716845@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"b4060858f5201489e11ab57063e72380c03c3b55/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b4060858f5201489e11ab57063e72380c03c3b55" Generalise Control.Monad.{sequence_,msum,mapM_,forM_} This finally takes the gloves off, and performs the first actual generalization in order to implement #9586. This re-exports the respective definitions for the 4 combinators defined in Data.Foldable. This way, importing Data.Foldable and Control.Monad unqualified won't bring conflicting definitions of those 4 entities into scope anymore. This change seems to have some minor effect on rule-firing, which causes some wibble in the test-case T4007 Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D226 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 21:18:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 21:18:26 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.67a702258269eef5047ce5cdf2152a3e@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by dfeuer): rwbarton mentions also `scanl1` and `scanr1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 21:43:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 21:43:17 -0000 Subject: [GHC] #9610: Missing fixity declaration for `Data.Foldable.{elem, notElem}` Message-ID: <042.e5a5bef8aede934077d0f4b4aff41cb0@haskell.org> #9610: Missing fixity declaration for `Data.Foldable.{elem,notElem}` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #9586 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `Data.Foldable.{elem,notElem}` is lacking the fixity declaration {{{#!hs infix 4 `elem`, `notElem` }}} to match their monomorphic `Data.List` counterparts' fixity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 21:47:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 21:47:59 -0000 Subject: [GHC] #9610: Missing fixity declaration for `Data.Foldable.{elem, notElem}` In-Reply-To: <042.e5a5bef8aede934077d0f4b4aff41cb0@haskell.org> References: <042.e5a5bef8aede934077d0f4b4aff41cb0@haskell.org> Message-ID: <057.ca01ffd4988323b721c2ef923b1f910b@haskell.org> #9610: Missing fixity declaration for `Data.Foldable.{elem,notElem}` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9586 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D227 | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D227 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 22:20:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 22:20:36 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.293ca4cb9262439f223fe5d5bbb1f2a4@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: low | Version: 6.12.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7880 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D211 | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"275dcafbfb6b371dd5d8943fa4df9c23e68f6165/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="275dcafbfb6b371dd5d8943fa4df9c23e68f6165" Add -fwarn-context-quantification (#4426) Summary: This warning (enabled by default) reports places where a context implicitly binds a type variable, for example type T a = {-forall m.-} Monad m => a -> m a Also update Haddock submodule. Test Plan: validate Reviewers: hvr, goldfire, simonpj, austin Reviewed By: austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D211 GHC Trac Issues: #4426 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 22:21:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 22:21:55 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.06f50ac0a2a80de8faf20ab81b7d0f86@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: low | Version: 6.12.3 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7880 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D211 | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 18 22:53:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Sep 2014 22:53:29 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.9e278d209be9ea32ef90e375a2d80212@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): I'm going to try and bisect this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 03:47:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 03:47:53 -0000 Subject: [GHC] #9611: Suggest the cause of "No instance" errors involving multiple versions of a package Message-ID: <047.46300571edbd036da850eb10c4f281a5@haskell.org> #9611: Suggest the cause of "No instance" errors involving multiple versions of a package -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Suppose I have packages A-1.0, A-1.1, and B-1.0 built against A-1.0, and A (both versions) defines a type T which B defines to be an instance of some class C. If I load A-1.1 and B-1.0 into ghci and try to use the C T instance I will get a "No instance for C T" error, because T refers to A-1.1:T and B only defines an instance for A-1.0:T. However, if I don't realize this is what's going on, the error will be quite confusing as B appears to define an instance C T. Or, A could define the class C, rather than the type T, with the same result. This is quite common nowadays because there is a newer version of transformers (0.4.1.0) than the one which ships with GHC (0.3.0.0) and it's easy to end up installing mtl or lens against 0.3.0.0, and then some other package which pulls in 0.4.1.0. It would be nice to give a hint about what is going on, like {{{ No instance for (MonadIO X) arising from a use of ?liftIO? In the expression: ... ... Note: there is an instance transformers-0.3.0.0:MonadIO X }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 04:01:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 04:01:22 -0000 Subject: [GHC] #9612: Use functional dependencies to give more specific error messages Message-ID: <047.362c86059a829fba275fe2ef97ed7a83@haskell.org> #9612: Use functional dependencies to give more specific error messages -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- An example from http://www.reddit.com/r/haskell/comments/2gryy8/stdlib_monad_error_messages_unhelpful/: {{{#!hs f ::(Eq a) => a -> (Int, a) -> Writer [(Int, a)] (Int, a) f y (n,x) | y == x = return (n+1, x) | otherwise = do tell (n,x) return (1,y) }}} {{{ Could not deduce (MonadWriter (Int, a) (WriterT [(Int, a)] Data.Functor.Identity.Identity)) arising from a use of ?tell? from the context (Eq a) bound by the type signature for f :: Eq a => a -> (Int, a) -> Writer [(Int, a)] (Int, a) at 180.hs:42:5-57 In a stmt of a 'do' block: tell (n, x) In the expression: do { tell (n, x); return (1, y) } In an equation for ?f?: f y (n, x) | y == x = return (n + 1, x) | otherwise = do { tell (n, x); return (1, y) } }}} GHC could realize that the class `MonadWriter m w` has a functional dependency `w -> m` and notice that there is an instance `MonadWriter w (WriterT w m1)` whose `m`-part unifies with that of the needed constraint. Therefore the error cannot be a missing instance, and GHC could give a more friendly error message like {{{ Couldn't match expected type `[(Int, a)]' with actual type `(Int, a)' when unifying the instance `MonadWriter w (WriterT w m1)' with the constraint `MonadWriter (Int, a) (WriterT [(Int, a)] Identity)' arising from a use of 'tell' In a stmt of a 'do' block: tell (n, x) In the expression: ... }}} (Or, if necessary, `Could not deduce [(Int, a)] ~ (Int, a) from the context (Eq a) ...`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 04:05:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 04:05:42 -0000 Subject: [GHC] #9613: when giving an error "No instance for C (a -> b)", suggest that a function may be underapplied Message-ID: <047.eea63fe88376c060310ab582974460c3@haskell.org> #9613: when giving an error "No instance for C (a -> b)", suggest that a function may be underapplied -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Suggestion of ibotty here: http://www.reddit.com/r/haskell/comments/2go92u/beginner_error_messages_in_c_vs_haskell/cklm7jk {{{ Prelude> print length :2:1: No instance for (Show ([a0] -> Int)) arising from a use of ?print? but there is an instance for (Show Int); maybe you omitted an argument to ?length? of type [a0]? In the expression: print length In an equation for ?it?: it = print length }}} I guess the trickiest part will be figuring out what function is underapplied. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 04:36:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 04:36:52 -0000 Subject: [GHC] #9613: when giving an error "No instance for C (a -> b)", suggest that a function may be underapplied In-Reply-To: <047.eea63fe88376c060310ab582974460c3@haskell.org> References: <047.eea63fe88376c060310ab582974460c3@haskell.org> Message-ID: <062.0ce067d9e2869684ed8e117bd4995999@haskell.org> #9613: when giving an error "No instance for C (a -> b)", suggest that a function may be underapplied -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by MikeIzbicki): This is roughly equivalent to the patch I suggest in: https://phabricator.haskell.org/D201 (TcErrors.lhs, line 1094ish). The difference is that my patch doesn't suggest the underapplied function name or the instances that do exist. It seems pretty straightforward to mention the existing instance, so I'll try to add that. I'm pretty sure it's in general impossible to name the argument. For example, in `show (length . head . tail)` which function do you say is underapplied? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 05:05:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 05:05:44 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.c8ccc5d2dcb1362d6073034d97c54380@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well, `ld -melf_i386` is surely OS-dependent, as neither OS X nor Windows uses ELF binaries. So the options you listed are not always the correct ones. (Also, that is actually an option needed for Cabal, not for GHC.) But speaking more generally, I don't see any advantage to GHC (or Cabal) trying to determine the proper way to invoke the C compiler at runtime. We already have a configure script that's run during installation of the binary distribution whose exact purpose is to determine things like what flags need to be passed to the C toolchain. So that is the logical place to put this 32-bit-on-64-bit detection. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 05:33:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 05:33:23 -0000 Subject: [GHC] #9614: ghc --print-(gcc|ld)-linker-flags broken Message-ID: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> #9614: ghc --print-(gcc|ld)-linker-flags broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ rwbarton at morphism:~/ghc$ ghc --print-gcc-linker-flags ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): Setting not found: "Gcc Linker flags" Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rwbarton at morphism:~/ghc$ ghc --print-ld-linker-flags ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): Setting not found: "Ld Linker flags" Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} In 2d2650bf65da3aede4e1c1ca4da623092b869dbe and subsequent commits (between 7.6 and 7.8) these settings fields became "C compiler link flags" and "ld flags". (I think, more or less.) The real problem is that Cabal still looks for the settings fields "Gcc Linker flags" and "Ld Linker flags". I guess this should be updated on the Cabal side though. (They are empty on at least Linux x86_64, which I guess is why nobody noticed before.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 06:31:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 06:31:25 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.ee767488e2a2d30aabe2ce774c0668d9@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): Bisection finished, the bad commit is this one: {{{ b9e49d3e9580e13d89efd1f779cb76f610e0d6e0 is the first bad commit [4/1912] commit b9e49d3e9580e13d89efd1f779cb76f610e0d6e0 Author: Simon Peyton Jones Date: Tue May 13 13:10:26 2014 +0100 Add -fspecialise-aggressively This flag specialises any imported overloaded function that has an unfolding, whether or not it was marked INLINEABLE. We get a lot of orphan SPEC rules as a result, but that doesn't matter provided we don't treat orphan auto-generated rules as causing the module itself to be an orphan module. See Note [Orphans and auto-generated rules] in MkIface. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 07:35:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 07:35:20 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.6364c32bf59fcb9303ccb9dd0b36da06@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: highest | Version: 6.12.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7880 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D211 | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: low => highest * status: closed => new * resolution: fixed => Comment: No, now, let's not close this. There's a pending change for 7.12, namely * making the warnings into an error. * getting rid of the `Qualified` constructor in `HsExplicitFlag` (we can use `Explicit` instead) * remove or deprecate `fwarn-context-quantification` (I suppose it should be deprecated until 7.14, sigh.) 7.12 isn't a milestone yet (Austin can you fix that?), so I'll milestone it for 7.10 so it doesn't get lost. I'll give it "highest" priority not because it's terribly vital but because it's easy and it'd be untidy to let it linger. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 07:56:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 07:56:07 -0000 Subject: [GHC] #9613: when giving an error "No instance for C (a -> b)", suggest that a function may be underapplied In-Reply-To: <047.eea63fe88376c060310ab582974460c3@haskell.org> References: <047.eea63fe88376c060310ab582974460c3@haskell.org> Message-ID: <062.d2f3ffdfdafeba101dd7c93c57f2c16a@haskell.org> #9613: when giving an error "No instance for C (a -> b)", suggest that a function may be underapplied -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ibotty): the underapplied function is {{{ length . head . tail }}} it is missing an argument of type {{{[[a0]]}}}. am i missing things? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 09:11:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 09:11:27 -0000 Subject: [GHC] #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date In-Reply-To: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> References: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> Message-ID: <062.c20fa772908cc8cbaaac12a7e3f02d24@haskell.org> #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date ----------------------------------------------+--------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by trommler): You are right I had GHCi disabled in `mk/build.mk`. Could we get a better error message from the build system or (perhaps better) remove the respective modules from `ell-split`'s list when building without GHCi? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 09:37:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 09:37:11 -0000 Subject: [GHC] #9615: GHC panic: Loading temp shared object failed Message-ID: <042.4e53618d00dd07f1d8d85e351181a7b3@haskell.org> #9615: GHC panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (Seemingly) Randomly happened when building with cabal (before many builds were fine in the same project): {{{ : ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc6776_0/ghc6776_359.so: undefined symbol: ganetizm2zi12_GanetiziUtils_newUUID1_info }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 09:48:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 09:48:26 -0000 Subject: [GHC] #9549: deriveConstants fails on OpenBSD In-Reply-To: <045.280f1382fe569e58794f97c954f259a6@haskell.org> References: <045.280f1382fe569e58794f97c954f259a6@haskell.org> Message-ID: <060.607d6198636d223ac6cd783d7b151f5b@haskell.org> #9549: deriveConstants fails on OpenBSD -------------------------------------+------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: OpenBSD | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by kgardas): Hi Roland, I'm afraid replacing nm with objdump is too invasive change. Few months ago various Solaris users including myself were working on extending deriveConstants to work with non-GNU nm and usage of nm -P is what's working on linux, freebsd, windows and solaris. I'm not sure about others but for example objdump is completely missing on Solaris so I would rather prefer to stick to what we do have now in nm functionality. Let me ask, isn't there some other OpenBSD's nm option which may be used to get that working? IMHO not using -P for OpenBSD and/or using some other option is still less invasive change than changing to objdump completely for all other platforms. Thanks for you care about OpenBSD! Karel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 09:51:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 09:51:48 -0000 Subject: [GHC] #9549: deriveConstants fails on OpenBSD In-Reply-To: <045.280f1382fe569e58794f97c954f259a6@haskell.org> References: <045.280f1382fe569e58794f97c954f259a6@haskell.org> Message-ID: <060.92d1f9f29f1a42d6113bc75aaf619482@haskell.org> #9549: deriveConstants fails on OpenBSD -------------------------------------+------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: OpenBSD | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by kgardas): * cc: kgardas (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 11:30:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 11:30:34 -0000 Subject: [GHC] #9580: Possible excessive leniency in interaction between coerce and data families? In-Reply-To: <047.e05803593a4302846c266dc183138a0f@haskell.org> References: <047.e05803593a4302846c266dc183138a0f@haskell.org> Message-ID: <062.adbd801f7c99fb5e05de683b616821be@haskell.org> #9580: Possible excessive leniency in interaction between coerce and data families? -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0aaf812ed0a4a4be9528b2e2f6b72bee7cd8002d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0aaf812ed0a4a4be9528b2e2f6b72bee7cd8002d" Clean up Coercible handling, and interaction of data families with newtypes This patch fixes Trac #9580, in which the Coercible machinery succeeded even though the relevant data constructor was not in scope. As usual I got dragged into a raft of refactoring changes, all for the better. * Delete TcEvidence.coercionToTcCoercion (now unused) * Move instNewTyConTF_maybe, instNewTyCon_maybe to FamInst, and rename them to tcInstNewTyConTF_maybe, tcInstNewTyCon (They both return TcCoercions.) * tcInstNewTyConTF_maybe also gets more convenient type, which improves TcInteract.getCoercibleInst * Define FamInst.tcLookupDataFamInst, and use it in TcDeriv, (as well as in tcInstNewTyConTF_maybe) * Improve error report for Coercible errors, when data familes are involved Another use of tcLookupDataFamInst * In TcExpr.tcTagToEnum, use tcLookupDataFamInst to replace local hacky code * Fix Coercion.instNewTyCon_maybe and Type.newTyConInstRhs to deal with eta-reduced newtypes, using (new) Type.unwrapNewTyConEtad_maybe and (new) Type.applyTysX Some small refactoring of TcSMonad.matchFam. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 11:30:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 11:30:34 -0000 Subject: [GHC] #5395: Context reduction stack overflow without undecidable instances In-Reply-To: <044.cc587d7f60fab1552eaf50eae3520e7a@haskell.org> References: <044.cc587d7f60fab1552eaf50eae3520e7a@haskell.org> Message-ID: <059.24843cbe518eb48887afc4ac30e445ca@haskell.org> #5395: Context reduction stack overflow without undecidable instances -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 Resolution: | Keywords: type family, Operating System: | termination Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c96c64fae0152bc53f48634d0ddd310ef4bc0105/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c96c64fae0152bc53f48634d0ddd310ef4bc0105" Increase -fcontext-stack=N default to 100 This addresses Trac #5395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 11:30:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 11:30:34 -0000 Subject: [GHC] #9528: typo in man-page/docs In-Reply-To: <048.b394457866f8d569617be702e8907986@haskell.org> References: <048.b394457866f8d569617be702e8907986@haskell.org> Message-ID: <063.1f6bcb4114e8605c6cc0db92af2f16e7@haskell.org> #9528: typo in man-page/docs -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ebb7334c02c3014283f5f997f239b3cf58476cbc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ebb7334c02c3014283f5f997f239b3cf58476cbc" Spelling error in flags.xml Fixes Trac #9528 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 11:30:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 11:30:34 -0000 Subject: [GHC] #9523: Typo in GHC Generics documentation In-Reply-To: <045.f6500f2e6e7dfb47345436a2e3e2ff3d@haskell.org> References: <045.f6500f2e6e7dfb47345436a2e3e2ff3d@haskell.org> Message-ID: <060.c781d3a931cb61878ad24011741f0354@haskell.org> #9523: Typo in GHC Generics documentation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2a5eb838f7aac048d71436acd6e9d32f1d7490e8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2a5eb838f7aac048d71436acd6e9d32f1d7490e8" Typo in comment in GHC.Generics Fixes Trac #9523 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 11:30:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 11:30:34 -0000 Subject: [GHC] #9529: Clean up cseProgram In-Reply-To: <045.1dfdc10036ea0fb30db7b134a1baa1ca@haskell.org> References: <045.1dfdc10036ea0fb30db7b134a1baa1ca@haskell.org> Message-ID: <060.919c6ea6a2e5269126d351c4ab425bfd@haskell.org> #9529: Clean up cseProgram -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"48f17f156c3bb608603575ade2788140fadab192/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="48f17f156c3bb608603575ade2788140fadab192" Use mapAccumL (refactoring only) Fixes Trac #9529 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 11:32:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 11:32:29 -0000 Subject: [GHC] #9523: Typo in GHC Generics documentation In-Reply-To: <045.f6500f2e6e7dfb47345436a2e3e2ff3d@haskell.org> References: <045.f6500f2e6e7dfb47345436a2e3e2ff3d@haskell.org> Message-ID: <060.11d33ae8cf983eac1a0cd4e6d2ae26e3@haskell.org> #9523: Typo in GHC Generics documentation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 11:33:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 11:33:41 -0000 Subject: [GHC] #9528: typo in man-page/docs In-Reply-To: <048.b394457866f8d569617be702e8907986@haskell.org> References: <048.b394457866f8d569617be702e8907986@haskell.org> Message-ID: <063.22279285a48471eccc2c8281e3d1e059@haskell.org> #9528: typo in man-page/docs -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Sorry.. the actual bug was already fixed by Reid; when I pulled and rebased, all that was left was a white-space change! No big deal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 11:33:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 11:33:57 -0000 Subject: [GHC] #9529: Clean up cseProgram In-Reply-To: <045.1dfdc10036ea0fb30db7b134a1baa1ca@haskell.org> References: <045.1dfdc10036ea0fb30db7b134a1baa1ca@haskell.org> Message-ID: <060.bff7f3265f58dc916c0cc5567bc8e7f0@haskell.org> #9529: Clean up cseProgram -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 11:35:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 11:35:00 -0000 Subject: [GHC] #9580: Possible excessive leniency in interaction between coerce and data families? In-Reply-To: <047.e05803593a4302846c266dc183138a0f@haskell.org> References: <047.e05803593a4302846c266dc183138a0f@haskell.org> Message-ID: <062.fa36af6e18d0b5607fc2cd82a6fda5cc@haskell.org> #9580: Possible excessive leniency in interaction between coerce and data families? -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: indexed- | types/should_fail/T9580 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_fail/T9580 * resolution: => fixed Comment: Thank you for identifying this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 11:35:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 11:35:36 -0000 Subject: [GHC] #5395: Context reduction stack overflow without undecidable instances In-Reply-To: <044.cc587d7f60fab1552eaf50eae3520e7a@haskell.org> References: <044.cc587d7f60fab1552eaf50eae3520e7a@haskell.org> Message-ID: <059.9e049e131a16eeb701831b60258f1231@haskell.org> #5395: Context reduction stack overflow without undecidable instances -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 Resolution: fixed | Keywords: type family, Operating System: | termination Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Done! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 11:37:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 11:37:51 -0000 Subject: [GHC] #9607: Type checking regression between GHC 7.6 and 7.8 In-Reply-To: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> References: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> Message-ID: <063.e6c524041324f660d4efd798cd482546@haskell.org> #9607: Type checking regression between GHC 7.6 and 7.8 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm going to re-open, because I'd like to collect examples of where ambiguity was actively sought in the wild. However I don't propose any action right now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 11:50:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 11:50:11 -0000 Subject: [GHC] #9612: Use functional dependencies to give more specific error messages In-Reply-To: <047.362c86059a829fba275fe2ef97ed7a83@haskell.org> References: <047.362c86059a829fba275fe2ef97ed7a83@haskell.org> Message-ID: <062.5c4b800fc7057a6f8d9cfd676b3f74bc@haskell.org> #9612: Use functional dependencies to give more specific error messages -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Which version of GHC are you using? With HEAD or 7.8 I get {{{ T9612.hs:6:33: Couldn't match expected type ?[(Int, a)]? with actual type ?(Int, a)? Relevant bindings include x :: a (bound at T9612.hs:5:8) y :: a (bound at T9612.hs:5:3) f :: a -> (Int, a) -> Writer [(Int, a)] (Int, a) (bound at T9612.hs:5:1) In the first argument of ?tell?, namely ?(n, x)? In a stmt of a 'do' block: tell (n, x) }}} which is certainly better than the one you display. I had to add `import Control.Monad.Trans.Writer.Strict` at the top. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 12:06:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 12:06:43 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.8c49c644b9762a48e898872708aaae3f@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: highest | Version: 6.12.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7880 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D211 | -------------------------------------+------------------------------------- Comment (by goldfire): I'm very late to this conversation, so please ignore me if this is silly. Why not just jump the gun and make this an error right now? Has anyone tried to see how many packages on Hackage this would break? Spreading the effects of this change over 3 releases (warning in 7.10, error in 7.12 while deprecating the warning flag, remove warning flag in 7.14) seems like a lot of overhead when the amount of affected code is (in my uneducated guess) very small. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 12:10:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 12:10:30 -0000 Subject: [GHC] #9580: Possible excessive leniency in interaction between coerce and data families? In-Reply-To: <047.e05803593a4302846c266dc183138a0f@haskell.org> References: <047.e05803593a4302846c266dc183138a0f@haskell.org> Message-ID: <062.39cb6fe2d4911f790af32f69e15bf29f@haskell.org> #9580: Possible excessive leniency in interaction between coerce and data families? -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: indexed- | types/should_fail/T9580 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dmcclean): Thanks for fixing it! I just have one followup question. One reason the coercion shouldn't have worked is because the newtype constructor wasn't in scope. But, with the newtype constructor in scope, should it be coercible or not? I thought that it should still not be, because the data family's role signature has all nominal arguments. The newtype instance happens to use its argument in a representational way, but should that property of the definition be visible when "looking through" the data family? (It may be the case that one of your refactoring changes addresses this, I don't understand most of those comments.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 12:18:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 12:18:55 -0000 Subject: [GHC] #9580: Possible excessive leniency in interaction between coerce and data families? In-Reply-To: <047.e05803593a4302846c266dc183138a0f@haskell.org> References: <047.e05803593a4302846c266dc183138a0f@haskell.org> Message-ID: <062.284cfd9642b38a08aef91c2b9b5955bd@haskell.org> #9580: Possible excessive leniency in interaction between coerce and data families? -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: indexed- | types/should_fail/T9580 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Cam you give a concrete example? And compare with whatever [http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ the paper] says? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 12:23:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 12:23:12 -0000 Subject: [GHC] #9611: Suggest the cause of "No instance" errors involving multiple versions of a package In-Reply-To: <047.46300571edbd036da850eb10c4f281a5@haskell.org> References: <047.46300571edbd036da850eb10c4f281a5@haskell.org> Message-ID: <062.3acb2b968ec09d3b427f5d22fe778762@haskell.org> #9611: Suggest the cause of "No instance" errors involving multiple versions of a package -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I expect this would be do-able (look in `TcErrors`), but it'd mean implementing a variant of the instance-matching code, to look for a match "by name" (where `p1:A.B.T` matches `p2:A.B.T`) rather than "by identity" where those two types are simply different. I can offer guidance if someone tackles this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 12:34:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 12:34:40 -0000 Subject: [GHC] #9580: Possible excessive leniency in interaction between coerce and data families? In-Reply-To: <047.e05803593a4302846c266dc183138a0f@haskell.org> References: <047.e05803593a4302846c266dc183138a0f@haskell.org> Message-ID: <062.5a8aebeb3c4d6a8b620ca8cc63d0bb35@haskell.org> #9580: Possible excessive leniency in interaction between coerce and data families? -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: indexed- | types/should_fail/T9580 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dmcclean): I think I may have been confused for 2 different reasons. First, I forgot that we are coercing in your example from Dimensional Int Double -> Double, which should work according to rule 2 in figure 2. I had it mixed up with converting from Dimensional Int Double -> Dimensional Int x (where there is a coercion from Double to x). Second, it doesn't appear to actually be possible to export the Quantity' constructor from the defining module at all. (If I put it in the export list, GHCi tells me that it isn't in scope even though it is and I checked the spelling three times.) So the scenario I was thinking of isn't possible for that reason too; I hadn't realized that this was a rule. I now think that with the change you made everything is correct, sorry for the confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 13:41:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 13:41:56 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.69a0b2a51597c2a97844abd5a65a7a50@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I thought this was going to be very complicated but it turned out to be very simple! The occurrence analyser does something called "glomming" if the application of imported RULES means that something that didn't look recursive becomes recursive. See `Note [Glomming]` in `OccurAnal`. Under these circumstances we group all the top-level bindings into a single massive `Rec`. But, crucially, I failed to repeat the occurrence analysis on this glommed set of bindings. That means that we weren't establishing the right loop breakers (indeed there were no loop breakers whatsoever), and that led immediately to the loop. The only surprising this is that it didn't happen before. Patch coming Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 13:51:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 13:51:20 -0000 Subject: [GHC] #9546: filterM is not a good consumer for list fusion In-Reply-To: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> References: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> Message-ID: <060.595db18e0840a9ff78dbab275cfe6f58@haskell.org> #9546: filterM is not a good consumer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:2 nomeata]: > LGTM. (I?m a bit doubtful about `INLINE`ing such a rather large function, but `mapM` and `sequence` are also `INLINE`, so if it is ok for them, I guess it ought to be ok for this). Would you be happier if it did a dance with `RULES`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 14:09:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 14:09:14 -0000 Subject: [GHC] #9580: Possible excessive leniency in interaction between coerce and data families? In-Reply-To: <047.e05803593a4302846c266dc183138a0f@haskell.org> References: <047.e05803593a4302846c266dc183138a0f@haskell.org> Message-ID: <062.2cc1705cb7bdd1cfe5b88b274742424d@haskell.org> #9580: Possible excessive leniency in interaction between coerce and data families? -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: indexed- | types/should_fail/T9580 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:8 dmcclean]: > I think I may have been confused for 2 different reasons. > > First, I forgot that we are coercing in your example from Dimensional Int Double -> Double, which should work according to rule 2 in figure 2. I had it mixed up with converting from Dimensional Int Double -> Dimensional Int x (where there is a coercion from Double to x). > > Second, it doesn't appear to actually be possible to export the Quantity' constructor from the defining module at all. (If I put it in the export list, GHCi tells me that it isn't in scope even though it is and I checked the spelling three times.) So the scenario I was thinking of isn't possible for that reason too; I hadn't realized that this was a rule. > > I now think that with the change you made everything is correct, sorry for the confusion. Did you use the proper export syntax, `Dimensional (Quantity')`? That's supposed to work. If you didn't get an unknown whatever error when exporting `Quantity'` from the defining module, I'm ''guessing'' that it exported the `Quantity'` ''type'' (produced by `DataKinds`) rather than the data constructor. I don't really know how that extension is supposed to work with module exports though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 14:14:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 14:14:20 -0000 Subject: [GHC] #9612: Use functional dependencies to give more specific error messages In-Reply-To: <047.362c86059a829fba275fe2ef97ed7a83@haskell.org> References: <047.362c86059a829fba275fe2ef97ed7a83@haskell.org> Message-ID: <062.d90534aa9c93cf385d718a52ddd5f45b@haskell.org> #9612: Use functional dependencies to give more specific error messages -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Oh, I meant for `tell` to be the one from mtl `Control.Monad.Writer`, sorry. {{{ class (Monoid w, Monad m) => MonadWriter w m | m -> w where writer :: (a,w) -> m a tell :: w -> m () listen :: m a -> m (a, w) pass :: m (a, w -> w) -> m a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 14:35:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 14:35:15 -0000 Subject: [GHC] #9580: Possible excessive leniency in interaction between coerce and data families? In-Reply-To: <047.e05803593a4302846c266dc183138a0f@haskell.org> References: <047.e05803593a4302846c266dc183138a0f@haskell.org> Message-ID: <062.d2bf2f8fef6e2245aa836b45168b216c@haskell.org> #9580: Possible excessive leniency in interaction between coerce and data families? -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: indexed- | types/should_fail/T9580 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dmcclean): No, I did not use the proper export syntax. I'm sorry, I wasn't aware of it. With the proper syntax it does work. Thank you both again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 15:26:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 15:26:10 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.b2c6ac03ee36a9e24709bc3d68cd2812@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mlen): I added the comment(s) and rebased over master. Will continue to work on patches for submodules during the weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 15:41:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 15:41:59 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.146b8ca63513796bc37b9357cf5de770@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): We probably want to be running with larger heap sizes when there are lots of cores, to counteract the synchronization overhead of stop-the-world GC across many cores. e.g. `+RTS -A32m` at least. Check whether your machines really have N cores, or if N/2 of those are hyperthreaded cores. I don't recommend including hyperthreaded cores in the -N value you give to GHC, it's better to leave them free to soak up any extra load while letting the GC synchronize properly. @carter, when you said "100% of ghc's cpu time was spent on user-space lock contention when I did the -j40 invocation.", how did you discover that? Which lock in particular? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 15:43:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 15:43:21 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.f3a4d0378de7dfa9da6fa4c88b96e02a@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr (added) * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 15:54:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 15:54:47 -0000 Subject: [GHC] #9610: Missing fixity declaration for `Data.Foldable.{elem, notElem}` In-Reply-To: <042.e5a5bef8aede934077d0f4b4aff41cb0@haskell.org> References: <042.e5a5bef8aede934077d0f4b4aff41cb0@haskell.org> Message-ID: <057.678b22ee11e8a795fe20201a4f21bf02@haskell.org> #9610: Missing fixity declaration for `Data.Foldable.{elem,notElem}` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9586 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D227 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"d48fed4e61afc2b51ac3a513290a66d89c929059/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d48fed4e61afc2b51ac3a513290a66d89c929059" Define fixity for `Data.Foldable.{elem,notElem}` This was probably just an oversight. With this change the fixity matches that from `Data.List.{elem,notElem`}`. Addresses #9610 Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D227 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 16:07:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 16:07:46 -0000 Subject: [GHC] #9610: Missing fixity declaration for `Data.Foldable.{elem, notElem}` In-Reply-To: <042.e5a5bef8aede934077d0f4b4aff41cb0@haskell.org> References: <042.e5a5bef8aede934077d0f4b4aff41cb0@haskell.org> Message-ID: <057.f6c29c8e0a6e3884b0de5836a7204ce9@haskell.org> #9610: Missing fixity declaration for `Data.Foldable.{elem,notElem}` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9586 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D227 | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 17:13:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 17:13:31 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.22d8499cde6152178e2783451537215f@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): Yeah, I definitely found that making the nursery larger helped A LOT, i'd done `-A50m` or `-A100m` on a few occasions, though I must admit I didn't think to do that for running GHC itself! Good point about hyperthreads, that would match my experience of only seeing good perf up to about 15-20ish for -N. This does raise the problem that the default -N flag should probably be set to the number of physical cores rather than hyper threaded cores, would that be a reasonable patch for me to write for GHC? (though of course theres the matter of correctly detecting that info in a portable way! ) I unfortunately dont have access anymore to that machine (or presently any SSH access to a mega core sized box) so I can't repro it to dig in deeper, I was using some cli tool who's name escapes me right now -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 18:53:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 18:53:45 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.9e4ace1c04ae2213e7dc1f6257ca4493@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------ Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Comment (by jrp): A significant increase in the number of failures since the last run: {{{ Unexpected results from: TEST="conc059 conc012 process011 T1735 TcTypeNatSimpleRun T3500b T5751 enum01 enum03 enum02 topHandler01 T7891 tc124 T5321FD T5030 T4801 T6048 T5631 T5837 T5642 T9020 T3064 parsing001 T1969 T5321Fun T783 T3294 cabal06 T5435_dyn_asm signals002" OVERALL SUMMARY for test run started at Fri Sep 19 19:43:39 2014 BST 0:07:28 spent to go through 4107 total tests, which gave rise to 16097 test cases, of which 15983 were skipped 0 had missing libraries 28 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 86 unexpected failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler01 [bad exit code] (threaded1,threaded2) ../../libraries/base/tests topHandler01 [bad stdout or stderr] (ghci) ../../libraries/process/tests process011 [bad exit code] (threaded1,threaded2) ../../libraries/process/tests process011 [bad stdout or stderr] (ghci) ../../libraries/unix/tests signals002 [bad stdout] (threaded1) ../../libraries/unix/tests signals002 [bad stdout or stderr] (ghci) cabal/cabal06 cabal06 [bad stdout] (normal) concurrent/should_run conc012 [bad exit code] (ghci) concurrent/should_run conc059 [bad stderr] (threaded1,threaded2) perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T3294 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler T5321FD [stat not good enough] (normal) perf/compiler T5321Fun [stat not good enough] (normal) perf/compiler T5631 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9020 [stat not good enough] (optasm) perf/compiler parsing001 [stat not good enough] (normal) rts T5435_dyn_asm [bad stdout] (normal) typecheck/should_compile T7891 [exit code non-0] (hpc,optasm,optllvm) typecheck/should_compile tc124 [exit code non-0] (hpc,optasm,optllvm) typecheck/should_run T1735 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) typecheck/should_run T1735 [bad stdout or stderr] (ghci) typecheck/should_run T3500b [exit code non-0] (hpc,optasm,threaded2,dyn,optllvm) typecheck/should_run T5751 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) typecheck/should_run T5751 [bad stdout or stderr] (ghci) typecheck/should_run TcTypeNatSimpleRun [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) typecheck/should_run TcTypeNatSimpleRun [bad stdout or stderr] (ghci) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 19:19:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 19:19:05 -0000 Subject: [GHC] #9445: GHC Panic: Tick Exhausted with high factor In-Reply-To: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> References: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> Message-ID: <063.ed7a13ea8565ce05c512e5f10fa29682@haskell.org> #9445: GHC Panic: Tick Exhausted with high factor -------------------------------------+------------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: panic Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: 5539 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by adinapoli): Sorry Simon, but I have seen this just now. Yes, the are the underlying C libraries SFML links to in order to build. On which platform are you? Windows I would image? Perhaps this might point you into the right direction: http://sfml-dev.org/download/sfml/2.1/ Let me know if I can assist somehow, and yes, 1630 is quite huge! Alfredo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 19:41:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 19:41:16 -0000 Subject: [GHC] #9546: filterM is not a good consumer for list fusion In-Reply-To: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> References: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> Message-ID: <060.5476ce9976ac67b465e9ae7a115135b8@haskell.org> #9546: filterM is not a good consumer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): I?d be happier if we had numbers (time, allocation, binary size). Have you started to play around with the list-fusion-lab framework? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 20:09:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 20:09:25 -0000 Subject: [GHC] #9616: Incorrect numbers from HpcMarkup.markup_plugin Message-ID: <045.62543f73d6d6d97fee65adbd6d383235@haskell.org> #9616: Incorrect numbers from HpcMarkup.markup_plugin -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Incorrect hour) | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `showBigNum` in the `openTick` function accidentally puts 0s in the wrong place when formatting large numbers. 12345 will be formatted as 120,345 instead of 012,345. The correct answer is probably to add some locale- specific numeric formatting stuff somewhere, but until then, I'll just fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 20:14:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 20:14:26 -0000 Subject: [GHC] #9101: Build 7.8.2 from sources on Windows/msys2 In-Reply-To: <047.9aaf79de73007bb10bd989466d9c86e1@haskell.org> References: <047.9aaf79de73007bb10bd989466d9c86e1@haskell.org> Message-ID: <062.a80cae996d199a66011056a514388c08@haskell.org> #9101: Build 7.8.2 from sources on Windows/msys2 -------------------------------------+------------------------------------- Reporter: cchantep | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * owner: => gintas Comment: I'm looking into this, updating the wikipage as I go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 20:34:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 20:34:50 -0000 Subject: [GHC] #9617: Try to replace `quot` and `rem` with `quotRem` when possible Message-ID: <045.cfeeb5e5d9fed80126dc2dfbece53602@haskell.org> #9617: Try to replace `quot` and `rem` with `quotRem` when possible -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If I define {{{#!hs myquot x y = fst (quotRem x y) myrem x y = snd (quotRem x y) bob :: Int -> Int -> Int bob x y = myquot x y + myrem x y }}} Then I get this beautiful thing with GHC 7.9 (I ''don't'' get anything beautiful in 7.8.3, so great work, compiler gurus!): {{{#!hs bob :: Int -> Int -> Int bob = \ (w_sWx :: Int) (w1_sWy :: Int) -> case w_sWx of _ { I# ww1_sWB -> case w1_sWy of _ { I# ww3_sWF -> case ww3_sWF of wild_aSo { __DEFAULT -> case quotRemInt# ww1_sWB wild_aSo of _ { (# ipv_aSr, ipv1_aSs #) -> I# (+# ipv_aSr ipv1_aSs) }; (-1) -> case ww1_sWB of wild1_aSu { __DEFAULT -> case quotRemInt# wild1_aSu (-1) of _ { (# ipv_aSx, ipv1_aSy #) -> I# (+# ipv_aSx ipv1_aSy) }; (-9223372036854775808) -> case overflowError of wild2_00 { } }; 0 -> case divZeroError of wild1_00 { } } } } }}} However, if I write {{{ jones :: Int -> Int -> Int jones x y = quot x y + rem x y }}} I don't get anything nice. What I'm thinking (perhaps out of ignorance) is that we might be able to use the `myquot` and `myrem` definitions if it's possible to get some sort of dead code elimination to recognize when one or the other is not used, at which point it can replace the `quotRemInt#` with `quotInt#` or `remInt#`. Then we can quit the silly `quotRem` dance in user code and just write what we actually mean. Of course, exactly the same thing applies to `divMod`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 20:45:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 20:45:36 -0000 Subject: [GHC] #9617: Try to replace `quot` and `rem` with `quotRem` when possible In-Reply-To: <045.cfeeb5e5d9fed80126dc2dfbece53602@haskell.org> References: <045.cfeeb5e5d9fed80126dc2dfbece53602@haskell.org> Message-ID: <060.b63b3839848b1cde1cb13b385fba50e2@haskell.org> #9617: Try to replace `quot` and `rem` with `quotRem` when possible -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think the dead code elimination is probably pretty simple here. If we see {{{#!hs case quotRemInt# x y of _ { (# q, r #) -> expr } }}} and either `q` or `r` is not free in `expr`, replace that with {{{#!hs case quotInt# x y of _ { q -> expr } }}} or the other way around. I don't know where code to do such a thing would belong, however. It certainly would have to be post-CSE. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 20:57:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 20:57:18 -0000 Subject: [GHC] #9546: filterM is not a good consumer for list fusion In-Reply-To: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> References: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> Message-ID: <060.208d8f4535a0d8cc6eaf80b04dc2ef7a@haskell.org> #9546: filterM is not a good consumer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:4 nomeata]: > I?d be happier if we had numbers (time, allocation, binary size). Have you started to play around with the list-fusion-lab framework? No, not yet. Unfortunately, finding actual uses to benchmark against is not so easy. Also unfortunately, GHC does not currently build for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 19 21:49:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Sep 2014 21:49:54 -0000 Subject: [GHC] #9618: Undocument ImpredicativeTypes Message-ID: <045.05901419138923a568c2731a51d0dcf7@haskell.org> #9618: Undocument ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I understand that Simon Peyton Jones intends to make `ImpredicativeTypes` work some day, but it doesn't work now. I think the thing to do for now is to remove it from the user manual. It can be put back in later if it's ever fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 03:03:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 03:03:01 -0000 Subject: [GHC] #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build In-Reply-To: <045.67b198827318e5a03441f1825701405b@haskell.org> References: <045.67b198827318e5a03441f1825701405b@haskell.org> Message-ID: <060.988360a381676fef8fa011f0f7ef09ee@haskell.org> #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by quantheory): I don't think that I have enough information to resolve this, but I've noticed some things that may help clarify the situation, for any onlookers or future developers who haven't already figured them out. Apologies if any of this is too obvious. 1) The `wrap`, `unwrap`, `cons`, and `nil` definitions have to be examined in combination to check correctness. All are, in effect, defined by the consumer. I think that it's a bit confusing to have a `Wrap` type that only contains `wrap`/`unwrap` when (aside from the trivial `wrap . unwrap = id` case) the four have to be examined together to be understood. I'm agnostic as to whether that should be addressed by replacing `Wrap` with a new type that contains all four, or if `wrap`/`unwrap` pairs are so closely linked that it justifies pairing them separately. Aside from `isoSimple`, I'm not sure if many `Wrap` definitions would be reusable for very many consumers. 2) Producers are relatively constrained due to the use of `forall` in `buildW` and `Wrap`. Since consumers choose the definition of `wrap`/`unwrap`/`cons`/`nil` they are much freer. In an ideal (but unproven) case, all producers using buildW would be good, given sufficient constraints on of consumers. 3) These rules seem to me to be ''sufficient'' to ensure that a consumer is correct (disregarding the treatment of _|_): {{{ wrap . unwrap $ cons = cons wrap . unwrap $ (\ _ _ -> nil) = \ _ _ -> nil }}} I've started to sketch a proof of this, but to be frank I'm rather new to this sort of analysis and not at all confident. I'd be perfectly happy either to discuss this, or for someone else to beat me there, or give a counterexample. (I'm also not sure that `unwrap . wrap = id` is important, though probably pairs with this property are easier to understand.) 4) I have much less confidence that my conditions in (3) are necessary than that they are sufficient. They hold for `isoSimple` and the `foldl` implementation by Takano Akio, but I have not quite wrapped my head around, for instance, the scanl implementation here: https://github.com/dolio/ww-fusion This seems to get to the vague neighborhood of the condition on cons in (3), but not quite there, which suggests that either that condition needs to be expanded, or else that this implementation fails for some use of scanl that I haven't tested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 03:57:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 03:57:10 -0000 Subject: [GHC] #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build In-Reply-To: <045.67b198827318e5a03441f1825701405b@haskell.org> References: <045.67b198827318e5a03441f1825701405b@haskell.org> Message-ID: <060.40530b38ee75b4b263ee159222b5ad8a@haskell.org> #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:5 quantheory]: > 1) The `wrap`, `unwrap`, `cons`, and `nil` definitions have to be examined in combination to check correctness. All are, in effect, defined by the consumer. Quite possibly. > I think that it's a bit confusing to have a `Wrap` type that only contains `wrap`/`unwrap` when (aside from the trivial `wrap . unwrap = id` case) the four have to be examined together to be understood. I'm agnostic as to whether that should be addressed by replacing `Wrap` with a new type that contains all four, or if `wrap`/`unwrap` pairs are so closely linked that it justifies pairing them separately. Aside from `isoSimple`, I'm not sure if many `Wrap` definitions would be reusable for very many consumers. Unclear. `wrap . unwrap = id` seems to strong?I don't ''think'' any non- trivial wrappers satisfy it. Joachim thinks there could be a way to use parametricity to come up with a better criterion, and he may very well be right, but whether even a weaker one would be sufficient to implement enough useful functions is unclear. > 2) Producers are relatively constrained due to the use of `forall` in `buildW` and `Wrap`. Since consumers choose the definition of `wrap`/`unwrap`/`cons`/`nil` they are much freer. In an ideal (but unproven) case, all producers using buildW would be good, given sufficient constraints on of consumers. What makes a producer valid is not so clear, but yes, it seems less complicated than the consumer side. > 4) I have much less confidence that my conditions in (3) are necessary than that they are sufficient. They hold for `isoSimple` and the `foldl` implementation by Takano Akio, but I have not quite wrapped my head around, for instance, the scanl implementation here: > > https://github.com/dolio/ww-fusion This implementation fails for some reason you haven't tested. There are very bad interactions between the "static" stuff and `reverse`, and between `scanl` and `reverse`, leading to incorrect results. I tend to blame the static stuff and the `scanl` wrapper, but we don't really know if they would work right in all circumstances without `reverse`. Your efforts to find "local" correctness criteria are appreciated. My sense is that the `scanl` wrapper and the static stuff are problematic because they throw away information that someone else needs. The static stuff is an optimization that may be obviated by work on the static argument transformation. Whether there is a valid wrapper for `scanl` is as yet unclear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 11:25:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 11:25:24 -0000 Subject: [GHC] #7863: Verbosity level for quieter Template Haskell In-Reply-To: <044.036cc2d0e36ca0d39d050837fff3a1a3@haskell.org> References: <044.036cc2d0e36ca0d39d050837fff3a1a3@haskell.org> Message-ID: <059.a24994a6c2ccd21467cf3c398c7e448a@haskell.org> #7863: Verbosity level for quieter Template Haskell -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Template | Keywords: linker Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #5647 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * related: => #5647 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 11:26:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 11:26:52 -0000 Subject: [GHC] #5647: CLI option to silence "Loading package foo ... linking ... done" output In-Reply-To: <042.1048680b7dc28f045a26f772130b9f58@haskell.org> References: <042.1048680b7dc28f045a26f772130b9f58@haskell.org> Message-ID: <057.89d66e573818166a2e1aca3ec4386cd1@haskell.org> #5647: CLI option to silence "Loading package foo ... linking ... done" output -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7863 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * difficulty: => Unknown * resolution: => duplicate * related: => #7863 Comment: Closing this ticket in favour of #7863 which sounds more promising -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 11:49:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 11:49:49 -0000 Subject: [GHC] #7863: Verbosity level for quieter Template Haskell In-Reply-To: <044.036cc2d0e36ca0d39d050837fff3a1a3@haskell.org> References: <044.036cc2d0e36ca0d39d050837fff3a1a3@haskell.org> Message-ID: <059.e7d284a0b8349443f48b40eccf2b4b54@haskell.org> #7863: Verbosity level for quieter Template Haskell -------------------------------------+------------------------------------- Reporter: dolio | Owner: hvr Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Template | Keywords: linker Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #5647 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: => hvr Comment: The actual change seems to be just a single character: {{{#!diff diff --git a/compiler/ghci/Linker.lhs b/compiler/ghci/Linker.lhs index 5b0251c..ecba45b 100644 --- a/compiler/ghci/Linker.lhs +++ b/compiler/ghci/Linker.lhs @@ -1292,7 +1292,7 @@ findFile mk_file_path (dir : dirs) \begin{code} maybePutStr :: DynFlags -> String -> IO () maybePutStr dflags s - = when (verbosity dflags > 0) $ + = when (verbosity dflags > 1) $ do let act = log_action dflags act dflags SevInteractive noSrcSpan defaultUserStyle (text s) }}} as `maybePutStr` is used for all linker-related progress logging output With that change, a GHCi session looks like {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.9.20140919: http://www.haskell.org/ghc/ :? for help ?:2> Control.DeepSeq.rnf () () it :: () ?:3> }}} for comparison, here's what this looks like in GHC 7.8.3: {{{ GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. ?:2> Control.DeepSeq.rnf () Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. () it :: () ?:3> }}} If we want it that way, I'll go forward and adapt any testsuite wobbles this may have caused. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 13:59:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 13:59:37 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.0448e1926d90fed7aab4088464ddf8d6@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: highest | Version: 6.12.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7880 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D211 | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 14:19:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 14:19:06 -0000 Subject: [GHC] #7863: Verbosity level for quieter Template Haskell In-Reply-To: <044.036cc2d0e36ca0d39d050837fff3a1a3@haskell.org> References: <044.036cc2d0e36ca0d39d050837fff3a1a3@haskell.org> Message-ID: <059.6fffc0addd3eea1ede5096f183e823dd@haskell.org> #7863: Verbosity level for quieter Template Haskell -------------------------------------+------------------------------------- Reporter: dolio | Owner: hvr Type: feature | Status: patch request | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Template | Keywords: linker Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #5647 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D232 | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D232 Comment: There were only two testcases whose output needed tweaking, so I went ahead and submitted a code-rev -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 14:48:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 14:48:11 -0000 Subject: [GHC] #9619: HPC Code Coverage complains when two exactly the same mix files are on the path Message-ID: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> #9619: HPC Code Coverage complains when two exactly the same mix files are on the path -------------------------------------+------------------------------------- Reporter: Kasper | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Code Coverage | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Cabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in moduleATest. Unfortunately, in a first version, the integration tests and unit tests for moduleA were both present in moduleATest. Therefore, the unit test suite (in UnitTests.hs) and the integration test suite (in IntegrationTests.hs) both 'use' the moduleATest by linking in tests from that module. This leads to cabal generating a directory integration-tests and a directory unit-tests with .mix files, but the moduleATest.mix file is present in both directories. When performing hpc sum and hpc markup to get the total result of the test runs I need to specify the directories where the mix files are present (so dist/hpc/mix/unit-tests and dist/hpc/mix/integration-tests) and it will then complain that it finds moduleATest.mix file twice. This issue is not present when using the -fhpc flag, as the directory structure with integration-tests and unit-tests is not present in the .hpc directory at that moment. That being said, I don't think it's a cabal issue as it's more or less expected what they're doing, generating the mix files necessary to instrument integration-tests and unit-tests separately. Priority put to lowest because I can work around it by diving moduleATest up in moduleATest and moduleAIntegrationTest, which is saner in the end anyway. But I guess somebody will come up with a use case where a split up isn't possible, in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 14:59:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 14:59:18 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder Message-ID: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Keywords: libffi lib64 | Operating System: Linux nixos | Type of failure: Building Architecture: Unknown/Multiple | GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- This is dfeuer's error message, but it is equivalent to mine on NixOS x86_64 {{{ "/home/dfeuer/GHC/7.8.3.bin/bin/ghc" -o utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir utils/genapply/dist/build -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts utils/genapply/dist/build/GenApply.o libffi/stamp.ffi.static-shared.install exists, but libffi/build/inst/lib/libffi.a does not. Suggest removing libffi/stamp.ffi.static-shared.install. make[1]: *** [libffi/build/inst/lib/libffi.a] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 }}} libffi.a is build and linked into libffi/build/inst/lib64 instead of libffi/build/inst/lib, but the includes and pkg-config specific stuff is still put into libffi/build/inst/lib. GHC looks in lib for libffi.a and fails, the current workaround is to copy the contents of libffi/build/inst/lib64 into libffi/build/inst/lib and type make again. Symlinking won't work because libffi seems to sanitize the build directory before building the library I'd like to note that when compiling via the Debian source snapshot, libffi is put in the correct place if I run ./configure without using perl boot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 15:29:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 15:29:34 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.52dffb1d7f748b8d2a006f5d5890cc42@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: | nixos Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I suspect this is due to a distro-specific autotools difference, especially in light of your last sentence. Can you attach your `libffi/build/configure` and `libffi/build/*/config.log` files? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 16:21:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 16:21:07 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.4ced21db791bcd0763f79d57544737b7@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: | nixos Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rezb1t): Added requested logs, I checked autoconf and automake and they don't appear to have patches applied. There could be some other difference happening because of NixOS, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 16:55:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 16:55:44 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.c8d2087a1cf5ecc584a481c22bb1e139@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * keywords: libffi lib64 nixos => libffi lib64 Comment: This is not just NixOS. I'm seeing it here on Fedora 20. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 16:56:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 16:56:57 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.8e3ffb8f27b388e398473487ca465efc@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: monoidal Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by monoidal): * owner: => monoidal Comment: I'm refactoring scripts to support Python 3. Not sure if I'll catch all incompatibilities; my goal is at least to successfully execute a failed and passed run under 3, and don't change the behavior over 2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 16:58:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 16:58:46 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.d1e93c4c6b81b53f9952afca71ff6e0e@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): But your workaround does not work for me. I then get a new message: {{{ make[1]: *** No rule to make target `libffi/build/inst/lib/libffi.so', needed by `rts/dist/build/libffi.so'. Stop. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 17:47:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 17:47:34 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.1a52cecbc70edd5558ea7162933d070d@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Aha, here is the difference. From libffi's configure.ac: {{{ multi_os_directory=`$CC $CFLAGS -print-multi-os-directory` case $multi_os_directory in .) ;; # Avoid trailing /. ../*) toolexeclibdir=$toolexeclibdir/$multi_os_directory ;; esac }}} Your `gcc -print-multi-os-directory` must print `../lib64`, while mine prints `../lib`. I don't yet see a great way to fix this, though... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 18:01:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 18:01:44 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.5af9f76f2615e8b507574e76a86d2be8@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:5 rwbarton]: > Your `gcc -print-multi-os-directory` must print `../lib64`, while mine prints `../lib`. > > I don't yet see a great way to fix this, though... I can verify that mine prints `../lib64`. It sounds likely that someone accidentally hardcoded `../lib` somewhere else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 18:08:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 18:08:56 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.1addaf6f37fd11bd77943ad06eae1fb7@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well it's not accidental. ghc's build system configures libffi with `--libdir=$(TOP)/libffi/build/inst/lib` with the intention that libffi should install its libraries into `libffi/build/inst/lib`. However libffi insists on installing its libraries into this mysterious "toolexeclibdir" instead. Seems like Gentoo ran into the same issue when packaging libffi: https://sourceware.org/ml/libffi-discuss/2014/msg00016.html Maybe we can adopt their workaround of `sed -i 's:@toolexeclibdir@:$(libdir):g' Makefile.in` before running libffi's configure script. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 18:35:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 18:35:15 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.efcdea061cf926b3933190f551be35b4@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): dfeuer, could you try building with this patch? {{{ diff --git a/libffi/ghc.mk b/libffi/ghc.mk index bc62ad9..67dedf9 100644 --- a/libffi/ghc.mk +++ b/libffi/ghc.mk @@ -69,6 +69,11 @@ $(libffi_STAMP_CONFIGURE): $(TOUCH_DEP) mv libffi/build/Makefile.in libffi/build/Makefile.in.orig sed "s/-MD/-MMD/" < libffi/build/Makefile.in.orig > libffi/build/Makefile.in + # libffi does not properly respect libdir; force it to do so. + # (https://sourceware.org/ml/libffi-discuss/2014/msg00016.html) + mv libffi/build/Makefile.in libffi/build/Makefile.in.orig + sed 's:@toolexeclibdir@:$$(libdir):g' < libffi/build/Makefile.in.orig > libffi/build/Makefile.in + # Their cmd invocation only works on msys. On cygwin it starts # a cmd interactive shell. The replacement works in both environments. mv libffi/build/ltmain.sh libffi/build/ltmain.sh.orig }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 19:24:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 19:24:26 -0000 Subject: [GHC] #7863: Verbosity level for quieter Template Haskell In-Reply-To: <044.036cc2d0e36ca0d39d050837fff3a1a3@haskell.org> References: <044.036cc2d0e36ca0d39d050837fff3a1a3@haskell.org> Message-ID: <059.6abb442c9d63c3c37d41c98816655adf@haskell.org> #7863: Verbosity level for quieter Template Haskell -------------------------------------+------------------------------------- Reporter: dolio | Owner: hvr Type: feature | Status: patch request | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Template | Keywords: linker Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #5647 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D232 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"9f7e3633c692dce75c27607131bd386178fb0fcf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9f7e3633c692dce75c27607131bd386178fb0fcf" Change linker message verbosity to `-v2` (re #7863) With this change, the linker status logging output such as Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. is suppressed unless verbosity level is `-v2` or higher. This is done to reduce the compiler message noise when TH is involved, which can reduce the visibiliy of compile warnings. Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D232 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 19:51:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 19:51:33 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.188e590878576af09855159d72930f04@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 20:23:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 20:23:36 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.46c212b2dcc9e8adfb42ad6a10f2a8f6@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): I'm also on gentoo/am64 and rwbarton's fix unbreaks build for me. I suggest pushing it as is. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 21:40:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 21:40:46 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.54878077dd059cf53c2d61d4b4fb6c7f@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"3daf0023d2dcf7caf85d61f2dc177f8e9421b2fd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3daf0023d2dcf7caf85d61f2dc177f8e9421b2fd" Set up framework for generalising Data.List to Foldables This renames the Data.List module to Data.OldList, and puts a new Data.List module into its place re-exporting all list functions. The plan is to leave the monomorphic versions of the list functions in Data.OldList to help smooth the transition. The new Data.List module then will simply re-export entities from Data.OldList and Data.Foldable. This refactoring has been placed in a separate commit to be able to better isolate any regressions caused by the actual list function generalisations when implementing #9586 This also updates the haskell2010, haskell98, and array submodules Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D228 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 21:45:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 21:45:34 -0000 Subject: [GHC] #9621: New Data.Foldable methods Message-ID: <042.d9d7ae0716ad2c4184a4d3189309853b@haskell.org> #9621: New Data.Foldable methods -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #9586 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- place-holder text; details to follow soon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 21:48:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 21:48:39 -0000 Subject: [GHC] #9621: New Data.Foldable methods In-Reply-To: <042.d9d7ae0716ad2c4184a4d3189309853b@haskell.org> References: <042.d9d7ae0716ad2c4184a4d3189309853b@haskell.org> Message-ID: <057.96bda0a2590518200e07110ec4f72414@haskell.org> #9621: New Data.Foldable methods -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9586 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"1812898c0332c6807201938911bb914633267d9d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1812898c0332c6807201938911bb914633267d9d" Turn a few existing folds into `Foldable`-methods (#9621) Turn `toList`, `elem`, `sum`, `product`, `maximum`, and `minimum` into `Foldable` methods. This helps avoiding regressions (and semantic differences) while implementing #9586 Reviewed By: austin, dfeuer, ekmett Differential Revision: https://phabricator.haskell.org/D231 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 21:48:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 21:48:39 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.39db745209ba2b4d96c6f83f11d7da17@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"1812898c0332c6807201938911bb914633267d9d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1812898c0332c6807201938911bb914633267d9d" Turn a few existing folds into `Foldable`-methods (#9621) Turn `toList`, `elem`, `sum`, `product`, `maximum`, and `minimum` into `Foldable` methods. This helps avoiding regressions (and semantic differences) while implementing #9586 Reviewed By: austin, dfeuer, ekmett Differential Revision: https://phabricator.haskell.org/D231 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 21:53:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 21:53:41 -0000 Subject: [GHC] #9568: Type classes that fully cover closed kinds In-Reply-To: <047.0403b5d3c61124bb9ff541418f195523@haskell.org> References: <047.0403b5d3c61124bb9ff541418f195523@haskell.org> Message-ID: <062.5a6cc5121dbb4cb5997ff692e6c9b579@haskell.org> #9568: Type classes that fully cover closed kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: new request | Milestone: ? Priority: lowest | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"05cf18f883bf2d49b53a1d25cb57eff3333eb0c9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="05cf18f883bf2d49b53a1d25cb57eff3333eb0c9" Generalise (some of) Data.List to Foldables (re #9568) This replaces the entities in Data.List conflicting with Data.Foldable with re-exports of the generalised version from Data.Foldable. As of this commit, the following compiles w/o error module XPrelude (module X) where import Control.Monad as X import Data.Foldable as X import Data.List as X import Prelude as X Reviewed By: austin, dfeuer, ekmett Differential Revision: https://phabricator.haskell.org/D229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 21:59:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 21:59:48 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.0dff1a1c57c1f212c7dd5baac949686b@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"ed65808cebf068a98f564f6ad962838c6526591b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ed65808cebf068a98f564f6ad962838c6526591b" Add missing changelog entries for current state of #9586 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 22:10:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 22:10:43 -0000 Subject: [GHC] #9621: New Data.Foldable methods In-Reply-To: <042.d9d7ae0716ad2c4184a4d3189309853b@haskell.org> References: <042.d9d7ae0716ad2c4184a4d3189309853b@haskell.org> Message-ID: <057.6a762bbe40e102a3f4b97844f9b0c077@haskell.org> #9621: New Data.Foldable methods -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9586 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: dfeuer (added) * version: 7.8.3 => Old description: > place-holder text; details to follow soon New description: See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/22828 The current version of the proposal at time of writing: > Add the following to `Foldable`: > > - `length` ? often stored as a separate field for //O(1)// access > - `null` ? called very often and slightly faster than `foldr (\_ _ -> False) True` for some containers > - `toList` ? may be the identity or nearly so, and this fact may not be statically available to the foldr/id rule > - `sum`, `product` ? may be cached internally in tree nodes for fast update, giving //O(1)// access; may be calculated in parallel. > - `maximum`, `minimum` ? //O(n)// for a search tree; //O(1)// for a finger tree. > - `elem` ? //O(log n)// for search trees; likely better for hash tables and such. > > **Don't** add anything to `Traversable`, because `scanl1` and `scanr1` are not worth the extra dictionary weight. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 22:13:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 22:13:38 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.357f9c8e16b53c850bf70532d4af4799@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rezb1t): The patch fixes the issue for me as well, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 22:14:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 22:14:30 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.52ae709fb23a8e5f22c1a7173f13f9c9@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Changes (by hvr): * related: => #9621 Comment: Replying to [comment:5 dfeuer]: > rwbarton points out that there are optimized versions of these for various things, and that most containers use `size` instead of `length`. Therefore, I would propose instead adding `size` and `null` to the `Foldable` class, with default definitions as above. Extending `Foldable` has become a ticket of its own at #9621 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 22:26:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 22:26:20 -0000 Subject: [GHC] #7863: Verbosity level for quieter Template Haskell In-Reply-To: <044.036cc2d0e36ca0d39d050837fff3a1a3@haskell.org> References: <044.036cc2d0e36ca0d39d050837fff3a1a3@haskell.org> Message-ID: <059.7e9f073200e06f123491ff511cf20f81@haskell.org> #7863: Verbosity level for quieter Template Haskell -------------------------------------+------------------------------------- Reporter: dolio | Owner: hvr Type: feature | Status: closed request | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Template | Keywords: linker Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #5647 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D232 | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed Comment: Please reopen if this is not what we want -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 23:13:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 23:13:49 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.1474c4c34727849cf8fe0f919ea856ef@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8731 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * status: new => closed * resolution: => duplicate * related: => #8731 Comment: I think this is likely a dupe of #8731 This is a problem that impacts many many projects directly and indirectly (and epecshows up when folks ) I'm marking it as a duplicate for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 20 23:45:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Sep 2014 23:45:44 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.2c06ee80acf828f311bad15f603d3906@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: monoidal Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D233 | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => patch * differential: => Phab:D233 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 00:05:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 00:05:15 -0000 Subject: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2. In-Reply-To: <046.611e1011b849d674524f2ee05d864a89@haskell.org> References: <046.611e1011b849d674524f2ee05d864a89@haskell.org> Message-ID: <061.e338797545faa284d8c4f286dc53e244@haskell.org> #5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:17 thomie]: Here's an updated link to [http://research.microsoft.com/pubs/151917 /divmodnote-letter.pdf Daan Leijen's paper]. Euclidean div/mod, along with other benefits, works much better than Haskell div/mod with the idea I've been playing with of implementing `div`-like things and `mod`-like things using `divMod`-like things. In particular, CSE can do some really nifty stuff with either `quotRem` or `divModEuclidean`, but it has no hope with `divMod` (at least as it's currently implemented) in the general case, because the latter has complicated code that gets all torn up before it gets to CSE. I don't know if there's a way to fix that. It does work out if one or both of the operands is known and there's sufficient inlining. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 01:56:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 01:56:17 -0000 Subject: [GHC] #9616: Incorrect numbers from HpcMarkup.markup_plugin In-Reply-To: <045.62543f73d6d6d97fee65adbd6d383235@haskell.org> References: <045.62543f73d6d6d97fee65adbd6d383235@haskell.org> Message-ID: <060.9a15bcd825430e54b16f2651034b8702@haskell.org> #9616: Incorrect numbers from HpcMarkup.markup_plugin -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Code | Version: 7.9 Coverage | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch Comment: The patch I just attached should fix the 0 placement. It also uses `dropWhileEnd` now instead of `reverse . dropWhile ... . reverse`, and adds left padding in a somewhat saner manner in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 03:28:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 03:28:58 -0000 Subject: [GHC] #1042: Floating point exception In-Reply-To: <043.a5be1d72d3d949715655e3ba90022338@haskell.org> References: <043.a5be1d72d3d949715655e3ba90022338@haskell.org> Message-ID: <058.a2415169ed0e12723472d2930ace823d@haskell.org> #1042: Floating point exception -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: #8695 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: igloo => * status: closed => new * resolution: fixed => Comment: I'm sorry to reopen an 8 year old bug, but I tripped over this today while attempting (unsuccessfully, so far) to write a version of `divModInt` that plays nice with CSE: {{{#!hs divModInt :: Int -> Int -> (Int, Int) (I# x) `divModInt` (I# y) = case x `divModInt#` y of (# q, r #) -> (I# q, I# r) divModInt# :: Int# -> Int# -> (# Int#, Int# #) x# `divModInt#` y# = case x' `quotRemInt#` y# of (# q, r #) -> (# q +# qadj, r +# radj #) where (# x', qadj, radj #) = if | isTrue# (x# ># 0#) && isTrue# (y# <# 0#) -> (# x# -# 1#, -1#, y# +# 1# #) | isTrue# (x# <# 0#) && isTrue# (y# ># 0#) -> (# x# +# 1#, -1#, y# -# 1# #) | otherwise -> (# x#, 0#, 0# #) }}} When I test this with {{{#!hs main = print $ divModInt minBound (-1) }}} I get a floating point exception. `GHC.Base.divMod` does not trip over this, even though it seems to be doing exactly the same arithmetic. As far as I can tell, this is ''supposed'' to be handled by `quotRemInt#` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 03:30:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 03:30:26 -0000 Subject: [GHC] #1042: Floating point exception In-Reply-To: <043.a5be1d72d3d949715655e3ba90022338@haskell.org> References: <043.a5be1d72d3d949715655e3ba90022338@haskell.org> Message-ID: <058.1cd713a5347e96b7d5d53476b5592d6b@haskell.org> #1042: Floating point exception -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: #8695 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 03:30:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 03:30:56 -0000 Subject: [GHC] #1042: Floating point exception In-Reply-To: <043.a5be1d72d3d949715655e3ba90022338@haskell.org> References: <043.a5be1d72d3d949715655e3ba90022338@haskell.org> Message-ID: <058.45262c3a4103f70a55521d660018cb54@haskell.org> #1042: Floating point exception -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: #8695 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Never mind. The check was elsewhere. Sorry folks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 08:28:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 08:28:50 -0000 Subject: [GHC] #9617: Implement `quot` and `rem` using `quotRem`; implement `div` and `mod` using `divMod` (was: Try to replace `quot` and `rem` with `quotRem` when possible) In-Reply-To: <045.cfeeb5e5d9fed80126dc2dfbece53602@haskell.org> References: <045.cfeeb5e5d9fed80126dc2dfbece53602@haskell.org> Message-ID: <060.a25d5c4925c9faa47662e66db3f6395f@haskell.org> #9617: Implement `quot` and `rem` using `quotRem`; implement `div` and `mod` using `divMod` -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Good news: It seems it may not even be necessary (for `Int`, at least) to find a way to turn the `quotRemInt#` back into `quotInt#` or `remInt#`?the performance difference there appears to be somewhere between tiny and nonexistent. It's not clear to me whether that will be the same for `divMod`, which adds a few more operations over `div` or `mod` (but fast ones). More good news: After bashing my head against it for a few hours, I managed to get `divMod` to do what I wanted. I had to swap the divide by zero test with the arithmetic overflow test. I don't understand ''why'' this made it work, but it seems to have done the job. It looks like this: {{{#!hs divZeroError# :: Void# -> (# Int#, Int# #) divZeroError# a = error "Divide by zero" overflowError# :: Void# -> Int# overflowError# a = error "Arithmetic overflow: attempted to divide minBound by -1" divModInt# :: Int# -> Int# -> (# Int#, Int# #) x# `divModInt#` y# | isTrue# (y# ==# (-1#)) && isTrue# (x# ==# (case minBound of I# mb -> mb)) = (# overflowError# void#, 0# #) | isTrue# (y# ==# 0#) = divZeroError# void# | isTrue# (x# ># 0#) && isTrue# (y# <# 0#) = case (x# -# 1#) `quotRemInt#` y# of (# q, r #) -> (# q -# 1#, r +# y# +# 1# #) | isTrue# (x# <# 0#) && isTrue# (y# ># 0#) = case (x# +# 1#) `quotRemInt#` y# of (# q, r #) -> (# q -# 1#, r +# y# -# 1# #) | otherwise = x# `quotRemInt#` y# divModInt :: Int -> Int -> (Int, Int) (I# x) `divModInt` (I# y) = case x `divModInt#` y of (# q, r #) -> (I# q, I# r) div :: Int -> Int -> Int {-# INLINE div #-} div x y = fst (divModInt x y) infixl 7 `div` mod :: Int -> Int -> Int {-# INLINE mod #-} x `mod` y = snd (divModInt x y) infixl 7 `mod` }}} Using these definitions, it seems things stay sufficiently similar long enough for CSE to do its job, so {{{#!hs divPlusMod :: Int -> Int -> Int divPlusMod x y = div x y + mod x y }}} compiles into something very similar to what you'd get from {{{#!hs divPlusModStandard :: Int -> Int -> Int divPlusModStandard x y = case divMod x y of (q, r) -> q + r }}} but with the proposed definitions, I'm getting quite a bit less code duplication, which seems to be a small but good thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 08:35:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 08:35:19 -0000 Subject: [GHC] #9617: Implement `quot` and `rem` using `quotRem`; implement `div` and `mod` using `divMod` In-Reply-To: <045.cfeeb5e5d9fed80126dc2dfbece53602@haskell.org> References: <045.cfeeb5e5d9fed80126dc2dfbece53602@haskell.org> Message-ID: <060.88b98d10a9590ff5969bccd869898902@haskell.org> #9617: Implement `quot` and `rem` using `quotRem`; implement `div` and `mod` using `divMod` -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Argh. It looks like I got that wrong. That's only working because it's too big to inline. `divMod` may just be hopeless. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 09:13:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 09:13:07 -0000 Subject: [GHC] #9622: GHCi command to solve a constraint Message-ID: <047.c9e54978cf24ee7d150efc16fa56ce28@haskell.org> #9622: GHCi command to solve a constraint -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be nice to have a `:solve` command for ghci that took a class constraint and returned either its derivation or an error message. A possible interface could look like so: {{{ ghci> :solve Eq (Maybe Type1, Bool) 1) instance Eq Type1 -- Defined in ?MyModule? 2) instance Eq a => Eq (Maybe a) -- Defined in ?GHC.Classes? 3) instance Eq (Maybe Type1) -- Put a ~ Int in 2) and use 1) 4) instance Eq Bool -- Defined in ?GHC.Classes? 5) instance (Eq a, Eq b) => Eq (a,b) -- Defined in ?GHC.Classes? 6) instance Eq (Maybe Type1, Bool) -- Put a ~ Maybe Type1, b ~ Bool in 5) and use 3), 4) ghci> :solve Eq (Int -> Int) No instance for Eq (Int -> Int) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 09:25:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 09:25:52 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.c84012db3f0f8f749a169513d22a591c@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"e7c1633203e33c4a1af866c8658683bcef20a514/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e7c1633203e33c4a1af866c8658683bcef20a514" Simplify import-graph a bit more This is preparatory refactoring for avoiding import cycles when `Data.Traversable` will be imported by `Control.Monad` and `Data.List` for implementing #9586 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 09:34:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 09:34:35 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.66df4ef8ae7a88b78d35f4d195bb52f6@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8731 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Feuerbach): carter: why do you think they are the same? There, the reason is the large number of field selectors. Here, I was able to check that removing some of the class derivations reduces the compile time significantly. I'm not convinced that fixing that issue will necessarily fix this one; they may (or may not) be inefficiencies in different parts of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 09:34:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 09:34:48 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.23a173a496b9521963c807579f99fd4e@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8731 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Feuerbach): * status: closed => new * resolution: duplicate => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 13:24:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 13:24:51 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.0e278466908bc17131442bad492770b1@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"835d874df1973b7e1c602a747b42b77095592a9c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="835d874df1973b7e1c602a747b42b77095592a9c" Make libffi install into a predictable directory (#9620) On some systems (depending on gcc multilib configuration) libffi would install into libffi/build/inst/lib64 even though we configure it with --libdir=libffi/build/inst/lib. There appears to be no way to get libffi to install to a predictable directory "out of the box", so we apply a small patch to Makefile.in. This is the same fix used in Gentoo's ebuild (https://bugs.gentoo.org/show_bug.cgi?id=462814). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 13:25:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 13:25:53 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.6435b18ff59ba1afa02c0772d6415bb4@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: fixed | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 13:27:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 13:27:03 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.98a4e2bead6e89db6dc02d714db504a3@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: fixed | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => merge * milestone: 7.10.1 => 7.8.4 Comment: Actually, might as well merge this too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 14:10:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 14:10:40 -0000 Subject: [GHC] #9622: GHCi command to solve a constraint In-Reply-To: <047.c9e54978cf24ee7d150efc16fa56ce28@haskell.org> References: <047.c9e54978cf24ee7d150efc16fa56ce28@haskell.org> Message-ID: <062.f9b05114e0b04595571a648545ddbff5@haskell.org> #9622: GHCi command to solve a constraint -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by monoidal: Old description: > It would be nice to have a `:solve` command for ghci that took a class > constraint and returned either its derivation or an error message. A > possible interface could look like so: > > {{{ > ghci> :solve Eq (Maybe Type1, Bool) > 1) instance Eq Type1 -- Defined in ?MyModule? > 2) instance Eq a => Eq (Maybe a) -- Defined in ?GHC.Classes? > 3) instance Eq (Maybe Type1) -- Put a ~ Int in 2) and use 1) > 4) instance Eq Bool -- Defined in ?GHC.Classes? > 5) instance (Eq a, Eq b) => Eq (a,b) -- Defined in ?GHC.Classes? > 6) instance Eq (Maybe Type1, Bool) -- Put a ~ Maybe Type1, b ~ Bool in > 5) and use 3), 4) > ghci> :solve Eq (Int -> Int) > No instance for Eq (Int -> Int) > }}} New description: It would be nice to have a `:solve` command for ghci that took a class constraint and returned either its derivation or an error message. A possible interface could look like so: {{{ ghci> :solve Eq (Maybe Type1, Bool) 1) Eq Type1 -- Defined in ?MyModule? 2) Eq a => Eq (Maybe a) -- Defined in ?GHC.Classes? 3) Eq (Maybe Type1) -- Put a ~ Int in 2) and use 1) 4) Eq Bool -- Defined in ?GHC.Classes? 5) (Eq a, Eq b) => Eq (a,b) -- Defined in ?GHC.Classes? 6) Eq (Maybe Type1, Bool) -- Put a ~ Maybe Type1, b ~ Bool in 5) and use 3), 4) ghci> :solve Eq (Int -> Int) No instance for Eq (Int -> Int) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 15:25:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 15:25:01 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.9b29d0653677309c6fbd75ecc05ce094@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8731 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Deriving a lot of instances for a lot of large types generates a lot of code. Language.Haskell.Exts.Annotated.Syntax desugared to a program with 126,396 terms and took 24.2 seconds to build (with -O0). By comparison, the longest (in terms of lines, roughly 2100) module Language.Haskell.Exts.Annotated.ExactPrint desugared to a program with only 12,181 terms and it took 2.7 seconds to build. So, I don't think there is anything wrong with the speed of deriving instances specifically. Now, it's possible that instance deriving could be made to generate smaller code than it currently does for some particular classes... but I didn't notice anything amiss scanning through the generated instances for Decl (with `-dsuppress-all -ddump-deriv -ddump-to-file`). So, I don't really think deriving is to blame here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 16:01:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 16:01:57 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd Message-ID: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The GHC tree has many instances of `reverse . dropWhile ... . reverse`. As well as being harder to read and work with (searching for those forms led me to discover #9616) this approach is less efficient than `dropWhileEnd`. I think I've found all the places this is used, and I'll submit a patch to fix all the instances except for tests and nofib. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 16:27:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 16:27:49 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.9873fc764059c11ab9494ea904ea5f8c@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch Comment: One use of `reverse . dropWhile isSpace . reverse` turned out to be embedded in what someone suggested correctly was a complete reimplementation of `unwords . words`, so I just used that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 17:10:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 17:10:51 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.5081091b872a7689293b78a2dca7431b@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => new * component: Compiler => libraries (other) Comment: So `dropWhileEnd` was not added to base until version 4.5 (ghc 7.4), so to allow compilation with older versions of ghc, it would have to be conditionally imported and defined in the files you changed: {{{#!haskell #if MIN_VERSION_base(4,5,0) import Data.List(dropWhileEnd) #endif }}} {{{#!haskell #if !MIN_VERSION_base(4,5,0) dropWhileEnd :: (a -> Bool) -> [a] -> [a] dropWhileEnd p = foldr (\x xs -> if p x && null xs then [] else x : xs) [] #endif }}} And most of these patches should go to Github, since that is where those projects are maintained: [http://github.com/haskell/cabal cabal], [http://github.com/haskell/filepath filepath], [http://github.com/haskell/haddock haddock] and [http://github.com/judah/haskeline haskeline]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 17:15:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 17:15:06 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.017fe740e0f3ae5b52eb685d37132d09@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"5ed12810e0972b1e0d408fe1355805746c4614f9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5ed12810e0972b1e0d408fe1355805746c4614f9" Move `mapM` and `sequence` to GHC.Base and break import-cycles This simplifies the import graph and more importantly removes import cycles that arise due to `Control.Monad` & `Data.List` importing `Data.Traversable` (preparation for #9586) Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D234 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 17:15:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 17:15:27 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.061729d6fe3e039a048878bd1d1d8e4e@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:2 thomie]: > So `dropWhileEnd` was not added to base until version 4.5 (ghc 7.4), so to allow compilation with older versions of ghc, it would have to be conditionally imported and defined in the files you changed I'll get on that. Does GHC <7.4 compile GHC 7.9, or can I skip that for the stuff in the compiler? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 17:17:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 17:17:03 -0000 Subject: [GHC] #9568: Type classes that fully cover closed kinds In-Reply-To: <047.0403b5d3c61124bb9ff541418f195523@haskell.org> References: <047.0403b5d3c61124bb9ff541418f195523@haskell.org> Message-ID: <062.60abf338c88bf5ae0e22c7385c86c116@haskell.org> #9568: Type classes that fully cover closed kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: new request | Milestone: ? Priority: lowest | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"1f7f46f94a95ab7fc6f3101da7c02529e1964f24/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1f7f46f94a95ab7fc6f3101da7c02529e1964f24" Generalise Data.List/Control.Monad to Foldable/Traversable This flips the switch and replaces the entities in `Data.List`/`Control.Monad` conflicting with `Data.{Foldable,Traversable}` with re-exports of the more general versions. As of this commit, the code below (which is also added as a test-case) compiles w/o error. module XPrelude (module X) where import Control.Monad as X import Data.Foldable as X import Data.List as X import Data.Monoid as X import Data.Traversable as X import Prelude as X This addresses #9568 Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D235 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 17:38:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 17:38:49 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.8ba39f3746d285427bb2facebb639148@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Last time I tried 7.6 did not even compile 7.9, so I believe you can skip that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 18:15:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 18:15:08 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.13731e8044496ffcebb7fc7b904c22ad@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8731 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): It undoubtedly is a bit unexpected if simply adding `deriving( Show )` or whatever, which seems such a little thing, generates seriously large amounts of object code. If someone feels able to investigate I would suggest: * Find out if any particular class is to blame. How much of the code is generated by which classes? * Study the generated code to see if it could be abstracted, so that instead of lots of code, there were calls to some suitable shared functions. Obviously there is a performance/code-size issue to worry about, but my guess is that while `Eq` and `Ord` might be performance-critical, `Read` and `Show` are not. But it would require some thoughtful investigation. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 18:35:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 18:35:38 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.ec0847228d772479efcfe6fe95e19337@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): It turns out [wiki:Repositories win32] also has its [https://github.com/haskell/win32 issue tracker] on Github. The patch for hsc2hs looks good to me, but rdr1.diff needs work. If you upload a new version with the same name, it will be overwritten. I don't think you can delete attachments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 18:37:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 18:37:59 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.bd6b003aed312381528f4e07f28ac59b@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): GHC is supposed to be able to be built with the previous two stable releases, so 7.9/7.10 should be buildable with 7.6 and 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 19:16:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 19:16:47 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.03082fd1bef524414f8542e291aef9f2@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: monoidal Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D233 | -------------------------------------+------------------------------------- Comment (by aspidites): Sorry about the delay. I replied inline while at work, but the email got kicked back because I wasn't signed in. I had this mostly done, but recently fried the motherboard on my home machine. I also was apparently foolish in that while I had changes committed locally, I didn't push them. Sorry about that. What I did find was that forsaking python 2.5 made the necessary changes rather trivial, but in my second stab at it, I was trying to preserve python 2.5 support. While the changes were trivial, there was a lot of mechanical changes that had me chasing my tail. In any case, I'm glad someone else picked up the ball on this, and apologize again for my lack of communication. I seem to be losing track of time in more than one place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 19:18:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 19:18:53 -0000 Subject: [GHC] #9549: deriveConstants fails on OpenBSD In-Reply-To: <045.280f1382fe569e58794f97c954f259a6@haskell.org> References: <045.280f1382fe569e58794f97c954f259a6@haskell.org> Message-ID: <060.7f6763162bcb0b7651361c0277cde006@haskell.org> #9549: deriveConstants fails on OpenBSD -------------------------------------+------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: OpenBSD | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by roland): Removing the -P option (and adapting the pattern matching) in DeriveConstants.hs yields the following error: {{{ "inplace/bin/ghc-stage1" -static -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package- key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o rts/HeapStackCheck.cmm:97:18: parse error on input `[' }}} Apparently this is due to a wrong value being derived for REP_bdescr_link: {{{ $ grep '#define REP_bdescr_link' ./includes/dist- derivedconstants/header/DerivedConstants.h #define REP_bdescr_link b0 }}} ...which in turn comes from nm's output: {{{ $ nm ./includes/dist-derivedconstants/header/tmp.o | grep REP_bdescr_link 00000001 C derivedConstantREP_bdescr_link }}} On the other hand, objdump outputs 9 instead of 1: {{{ $ objdump -t ./includes/dist-derivedconstants/header/tmp.o | grep REP_bdescr_link 0000000000000009 O *COM* 0000000000000001 derivedConstantREP_bdescr_link }}} With this value (9), REP_bdescr_link is derived as 'b64' instead of 'b0' and thus HeapStackCheck.cmm compiles. No matter what options are passed to OpenBSD's nm, it won't output '9' for derivedconstantREP_bdescr_link. Does this have to be handled differently on different systems or is there another way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 19:34:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 19:34:34 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.50823781f8200be7fa4368e4cf884817@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: monoidal Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D233 | -------------------------------------+------------------------------------- Comment (by thomie): @aspidites: you could make it up for it by reviewing the final patch on [wiki:Phabricator phabricator] :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 19:36:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 19:36:22 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.e40f3cf5360e49ff90448b98844c2267@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: monoidal Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D233 | -------------------------------------+------------------------------------- Comment (by aspidites): Deal. I just set myself an alarm to do this immediately after work tomorrow. (I have a large project due for school this afternoon) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 20:04:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 20:04:10 -0000 Subject: [GHC] #9549: deriveConstants fails on OpenBSD In-Reply-To: <045.280f1382fe569e58794f97c954f259a6@haskell.org> References: <045.280f1382fe569e58794f97c954f259a6@haskell.org> Message-ID: <060.524ca4c54ccc33a01f254db8bb024911@haskell.org> #9549: deriveConstants fails on OpenBSD -------------------------------------+------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: OpenBSD | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Yes, someone (maybe you roland?) reported the same problem on #ghc a couple months ago. I agree there doesn't seem to be any way to get the relevant information out of OpenBSD's nm. GHC contains ''three'' different reimplementations of various parts of autoconf's functionality (DeriveConstants, mkGmpDerivedConstants, hsc2hs). I'm increasingly tempted to tear out all of them and replace them with a pile of autoconf. But, I'm not going to get around to it any time soon. In the short term, we could detect in GHC's configure whether `nm -P` has (one of) the expected output(s) on a test object file, and if not, try `objdump` instead; then put whichever one worked into a new autoconf variable and use that as the `--nm-program` argument to DeriveConstants, and teach it to parse the objdump format too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 20:24:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 20:24:52 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.e983da2eaa6d116304a1e7285c7cac15@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): There's a separate potential issue I don't think is likely to affect any of these uses: `dropWhileEnd` is defined like this: {{{#!hs dropWhileEnd :: (a -> Bool) -> [a] -> [a] dropWhileEnd p = foldr (\x xs -> if p x && null xs then [] else x : xs) [] }}} This is (relatively) strict in the elements of the list and (relatively) lazy in its spine. This is the opposite of the `reverse . dropWhile p . reverse` behavior. There should (according to some theory) also be a {{{#!hs dropWhileEndLE :: (a -> Bool) -> [a] -> [a] dropWhileEndLE p = foldr (\x xs -> if null xs && p x then [] else x : xs) [] }}} that's the other way around. We could call such a thing `dropWhileEnd'`, but that naming convention clashes with another pair of things that should exist and don't: {{{#!hs takeWhileEnd :: (a -> Bool) -> [a] -> [a] takeWhileEnd p = fst . foldr go ([], False) where go x (rest, done) | not done && p x = (x:rest, False) | otherwise = (rest, True) takeWhileEnd' p = fst . foldr go ([], False) where go x (rest, done) | p x && not done = (x:rest, False) | otherwise = (rest, True) }}} `takeWhileEnd'` is strict in both the elements and the spine (assuming a strict predicate), while `takeWhileEnd` is only strict in the spine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 21:29:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 21:29:00 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.cd239c4baaa528498cabfa6aa6a5030e@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"b8f583928fa6cb5371a872fc73080d2002dd87d9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b8f583928fa6cb5371a872fc73080d2002dd87d9" Export `Monoid(..)`/`Foldable(..)`/`Traversable(..)` from Prelude This finally exposes also the methods of these 3 classes in the Prelude in order to allow to define basic class instances w/o needing imports. This almost completes the primary goal of #9586 NOTE: `fold`, `foldl'`, `foldr'`, and `toList` are not exposed yet, as they require upstream fixes for at least `containers` and `bytestring`, and are not required for defining basic instances. Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D236 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 21 23:03:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Sep 2014 23:03:19 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.f4b5dc291315bfbeb4a2e4f2d0d054e6@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8731 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I performed the following list of modifications to the program and recorded the size in terms after desugaring after each step: ||=step=||=program size (terms)=|| ||original|| 126396|| ||remove everything but data decls|| 122877|| ||remove deriving Generic|| 106339|| ||remove deriving Data|| 78544|| ||remove deriving Traversable|| 70886|| ||remove deriving Foldable|| 59332|| ||remove deriving Functor|| 55041|| ||remove deriving Show|| 42848|| ||remove deriving Ord|| 11044|| ||remove deriving Eq|| 2244|| ||remove deriving Typeable|| 1140|| So, the cost of each class is ||=class=||=terms=|| ||Ord|| 31804|| ||Data|| 27795|| ||Generic|| 16538|| ||Show|| 12193|| ||Foldable|| 11554|| ||Eq|| 8800|| ||Traversable|| 7658|| ||Functor|| 4291|| ||Typeable|| 1104|| So no individual class is adding a particularly egregious amount of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 01:28:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 01:28:07 -0000 Subject: [GHC] #9568: Type classes that fully cover closed kinds In-Reply-To: <047.0403b5d3c61124bb9ff541418f195523@haskell.org> References: <047.0403b5d3c61124bb9ff541418f195523@haskell.org> Message-ID: <062.88aec8a4322e12abb1f93546fd5b8c64@haskell.org> #9568: Type classes that fully cover closed kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: closed request | Milestone: ? Priority: lowest | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => wontfix Comment: I'm assuming that those two recent commits reference this ticket in error. And, it seems that the original poster agrees that the requested feature is invalid, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 01:30:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 01:30:04 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.32461abd714d1aa57d5be7fb359717c3@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by goldfire): See also comment:4:ticket:9568 and comment:5:ticket:9568 which were posted to the wrong ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 02:31:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 02:31:58 -0000 Subject: [GHC] #9624: "Unlikely constraint" recognition Message-ID: <045.b973b2c95bf93319246aa07c85b8ac73@haskell.org> #9624: "Unlikely constraint" recognition -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Some constraints or combinations are relatively unlikely to appear in correct code, or at least correct code written by beginners. A few tiny examples: {{{#!hs (Integral a, Fractional a) => -- Possible, but rare, in correct code. (Integral a, RealFloat a) => -- Rather less possible in correct code. (Num a, Foldable a) => -- Possible, but unlikely for a beginner. (Fractional [a]) => (Show (A -> B)) => }}} The current error messages when constraints like these are not satisfied does nothing to suggest that they are unlikely to be correct or to explain to a beginner what kinds of mistakes can lead to errors like this. I imagine some people who teach classes using Haskell will have an idea of which specific things are worth singling out for a special explanation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 07:40:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 07:40:03 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.1b1ff775364d2e759b5415e9d28cebe7@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:19 goldfire]: > See also comment:4:ticket:9568 and comment:5:ticket:9568 which were posted to the wrong ticket. Thanks for noticing. With so many commits this was bound to happen... :-) ----- In [changeset:"05cf18f883bf2d49b53a1d25cb57eff3333eb0c9/ghc"]: {{{ Generalise (some of) Data.List to Foldables (re #9568) This replaces the entities in Data.List conflicting with Data.Foldable with re-exports of the generalised version from Data.Foldable. As of this commit, the following compiles w/o error module XPrelude (module X) where import Control.Monad as X import Data.Foldable as X import Data.List as X import Prelude as X Reviewed By: austin, dfeuer, ekmett Differential Revision: https://phabricator.haskell.org/D229 }}} ----- In [changeset:"1f7f46f94a95ab7fc6f3101da7c02529e1964f24/ghc"]: {{{ Generalise Data.List/Control.Monad to Foldable/Traversable This flips the switch and replaces the entities in `Data.List`/`Control.Monad` conflicting with `Data.{Foldable,Traversable}` with re-exports of the more general versions. As of this commit, the code below (which is also added as a test-case) compiles w/o error. module XPrelude (module X) where import Control.Monad as X import Data.Foldable as X import Data.List as X import Data.Monoid as X import Data.Traversable as X import Prelude as X This addresses #9568 Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D235 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 08:43:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 08:43:25 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.1cd2b6d6b159522d78eeab26bc6d7b37@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8731 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): For those who want to play around with the module: You can fetch it from http://hackage.haskell.org/package/haskell-src- exts-1.16.0/src/src/Language/Haskell/Exts/Annotated/Syntax.hs and it is has no dependencies inside `haskell-src-exts`, so you can just download and compile it in isolation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 08:44:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 08:44:02 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.e8b7e061edde41440cb873994fa07099@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"27b937e5012c902a513dbc3b6ae24bf490ce656e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="27b937e5012c902a513dbc3b6ae24bf490ce656e" Fix windows breakage from 5ed12810e0972b1e due to import cycles Refs #9586 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 08:59:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 08:59:04 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.cc2ed2f3829fa1afab441457453402e0@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8731 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > Study the generated code to see if it could be abstracted, so that instead of lots of code, there were calls to some suitable shared functions. Looking at the `Ord` code (which seems to be the largest): * It seems that it could be made much smaller using `<>` (which is `EQ <> x = x` and `y <> _ = y` otherwise) instead of nested case expressions. I guess there would be a performance hit, though. * Do we really have to provide separate definitions for `compare` and `<` and `<=` and `>` and `>=`? Maybe using the default implementation for all methods but `compare` is good enough, and could bring code size down considerably. Overreaching spontaneous idea: Add a method `generalCompare :: r -> r -> r -> a -> a -> r` to the `Ord` class. Implement that in deriving clauses, and have the default implementations use that. (e.g. `(<) = generalCompare True False False`). Should be faster than using `compare` + pattern matching. OTOH. all constructors of `Comparing` are static values, so there is probably not much to win here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 09:06:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 09:06:41 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.cd9035931593156b3052cf5f8967cfaf@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8731 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Obviously, people have considered my second suggest before, see `Note [Do not rely on compare]` in [source:ghc/compiler/typecheck/TcGenDeriv.lhs#L300]... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 09:21:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 09:21:48 -0000 Subject: [GHC] #8918: Network package doesn't load under GHC 7.8 RC on windows (?) In-Reply-To: <047.1e9ba761fa9dc023d8755ecfd2935d3e@haskell.org> References: <047.1e9ba761fa9dc023d8755ecfd2935d3e@haskell.org> Message-ID: <062.dbce25c4d6d0d3c040dcecdf62955299@haskell.org> #8918: Network package doesn't load under GHC 7.8 RC on windows (?) -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries | Version: 7.8.1-rc1 (other) | Keywords: Resolution: invalid | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: The network package has been [https://github.com/haskell/network/issues/129 fixed]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 09:55:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 09:55:52 -0000 Subject: [GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. In-Reply-To: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> References: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> Message-ID: <058.4ddb0c8d56f7fc4cb9604c8cb0977f5f@haskell.org> #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: type family, Resolution: | ambiguity check Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: #9607 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by oleg): I have played with giving type annotations for quite a long time, without success. Let's take the same example: {{{ {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE AllowAmbiguousTypes #-} module T where type family Arr (repr :: * -> *) (a :: *) (b :: *) :: * class ESymantics repr where int :: Int -> repr Int add :: repr Int -> repr Int -> repr Int lam :: (repr a -> repr b) -> repr (Arr repr a b) app :: repr (Arr repr a b) -> repr a -> repr b {- te4 :: (Arr repr (Arr repr Int Int) (Arr repr Int Int) ~ Arr repr (Arr repr Int Int) (Arr repr Int b), ESymantics repr) => repr b -} te4 :: forall repr. ESymantics repr => repr Int te4 = let c3 :: forall a. repr (Arr repr (Arr repr a a) (Arr repr a a)) c3 = lam (\f -> lam (\x -> f `app` ((f :: repr (Arr repr a a)) `app` ((f `app` (x::repr a) :: repr a) :: repr a) ) :: repr a) :: repr (Arr repr a a)) in (c3 `app` (lam (\x -> x `add` int 14))) `app` (int 0) }}} Here I have annotated everything of importance, I think. All binders are annotated and all applications are annotated. We really don't want to do it in real programs. And yet the type checker is unhappy: {{{ Could not deduce (Arr repr a0 a ~ Arr repr a a) from the context (ESymantics repr) bound by the type signature for te4 :: ESymantics repr => repr Int at /tmp/u.hs:(26,8)-(27,34) NB: ?Arr? is a type function, and may not be injective The type variable ?a0? is ambiguous Expected type: repr (Arr repr a0 a) Actual type: repr (Arr repr a a) Relevant bindings include x :: repr a (bound at /tmp/u.hs:30:29) f :: repr (Arr repr a a) (bound at /tmp/u.hs:30:18) c3 :: repr (Arr repr (Arr repr a a) (Arr repr a a)) (bound at /tmp/u.hs:30:7) te4 :: repr Int (bound at /tmp/u.hs:28:1) In the first argument of ?app?, namely ?f? In the expression: f `app` ((f :: repr (Arr repr a a)) `app` ((f `app` (x :: repr a) :: repr a) :: repr a)) :: repr a }}} We see all bindings in scope have the right type; we don't seem to have any more places to add a type annotation that change things. I wonder what wrong could happen if we just assume injectivity in such cases. Let's take an example of type family Add to add two type-level numerals (represented in unary, for example). Clearly Add is not injective. Therefore, from the constraint Add x y ~ Add 1 2 we cannot infer that x ~ 1 and y ~ 2. Although x~1, y~2 do satisfy the constraint, there are other satisfactory pairs. Suppose however that x and y are not mentioned anywhere else in the type or the type environment. Then setting them to x~1 and y~2 will not lead to any contradiction. Hence my suggestion: if type checking gets stuck on trying to deduce the equality constraint LHS ~ RHS, try to solve this constraint using unification (that is, assume injectivity of all type functions used in the constraint). Unification will give a set of equalities x1 ~ y1, x2 ~ y2, etc. Of these equalities, accept only those that involve a type variable that appears only once in the inferred equalities and does not appear anywhere else (in types or the type environment). Repeat the type checking using the accepted equalities. What do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 11:24:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 11:24:39 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.a666e5923ca3be1f571c38a052ff8bb1@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Replying to [comment:13 rwbarton]: OK, I think you are right the settings file is the better place to set options according to the ACTUAL_HOST/TARGET pair. I tried modifying the file manually and, at least initially, "-m32" for "C compiler flags" is necessary and sufficient for GHC alone. It apparently gets passed through to gcc when it does {{{-x assembler}}}, so we don't need "assembler flags" nor "-opta-m32". Also, "-optl-m32" is not needed at all, at least for simple packages. This is all very encouraging. However, I need to manually pass {{{--ld-option="-melf_i386"}}} to cabal, because the "ld flags" are ignored by cabal. I will investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 12:13:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 12:13:43 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.e5b244cd2c66f30105d7958a0e1481ca@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): I tried investigating why cabal ignores {{{"ld flags"}}} from the {{{$PREFIX/lib/ghc-7.8.3/settings}}} file. Cabal doesn't now about {{{"ld flags"}}}, but it does know about {{{"Ld Linker flags"}}}. However, just setting {{{"Ld Linker flags"}}} in the file doesn't help. I code-dived in GHC and it mentions each of the keys exactly once: in the template for the settings file {{{ settings.in: ("ld flags", "@SettingsLdFlags@"), }}} and when dealing with commandline arguments {{{ ghc/Main.hs-mode_flags = [...] ghc/Main.hs- [ Flag k' (PassFlag (setMode (printSetting k))) ghc/Main.hs- | k <- ["Project version", [...] ghc/Main.hs: "Ld Linker flags"], }}} It seems the two keys are different things, from different namespaces --- almost all of the keys in {{{ghc/Main.h}}} differ from their {{{settings.in}}} wording. BTW, there is also a single possibily relevant comment in the cabal source code, but I hope the part about ld is outdated and, anyway, I don't understand it: {{{ Cabal/Distribution/Simple.hs- -- The C compiler's compilation and linker flags (e.g. Cabal/Distribution/Simple.hs: -- "C compiler flags" and "Gcc Linker flags" from GHC) have already Cabal/Distribution/Simple.hs- -- been merged into ccFlags, so we set both CFLAGS and LDFLAGS Cabal/Distribution/Simple.hs- -- to ccFlags Cabal/Distribution/Simple.hs- -- We don't try and tell configure which ld to use, as we don't have Cabal/Distribution/Simple.hs- -- a way to pass its flags too }}} Looking at GHC code for other settings, I'd guess that GHC may not read and merge {{{"ld flags"}}} with other ld options (perhaps because it doesn't call ld, but cabal does?). And so cabal doesn't learn this part of ld setting from GHC. But the GHC source code naming of the gcc linker flags and the /usr/bin/ld flags is not easy to follow and sometimes the gcc linker flags seem to be used for the system linker, etc., so it's not obvious to me if GHC or cabal is to blame or both. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 13:04:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 13:04:13 -0000 Subject: [GHC] #8026: DatatypeContexts should be fixed, not deprecated In-Reply-To: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> References: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> Message-ID: <059.9f90ba8ef3fe444772f1b6d13da804a5@haskell.org> #8026: DatatypeContexts should be fixed, not deprecated -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by yokto): I like the idea of fixing this too. The main Idea would be to hide Contexts from sight. As an example of how this could be useful consider Num were a newtype instead of a type class {{{ newtype (Prelude.Num n) => Num n = Num n newtype Int = Num Prelude.Int (+) :: Num n -> Num n -> Num n }}} This would mean you could actually make instances {{{ instance SomeClass (Num n) }}} that don't conflict with all other instances {{{ instance (Num n) => SomeClass n instance SomeClass Char }}} crash and even if you enable ugly extensions like UndecidableInstances this can not fix your problems if you want to use type families or functional dependencies. you can not make an instance {{{ class SomeClass a b | a -> b instance (Num n) => SomeClass n b }}} without immediately blocking all other possible Instances. Maybe these DatatypeContexts based containers are a bit less flexible than common classes in that they don't mix, but if you know they don't have to mix it makes instances a lot easier and safer. of course you can always add the context explicitly but it would be nice if ghc infer them. As gidyn said I don't think this would change the type system overly much. You would just get contexts that don't need not be explicitly stated. Every time you do context checks you can easily derive them from the type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 13:29:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 13:29:05 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.83792bfcf6a19f26abff5c4ff1497e40@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Duncan helped me with that one, so I have some hypotheses now. The old GHC 7.6.3 has no "ld flags" nor "Ld Linker flags" in the settings file, but it somehow produces "Ld Linker flags" in the {{{ghc --info}}} output and this is what cabal expects. However, GHC 7.8.3 has "ld flags" in the settings file and doesn't produce "Ld Linker flags" at all in {{{ghc --info}}}. This may be a bug or a half-done transition to another convention, but right now it fools the newest cabal. BTW, I can't probably specify "Ld Linker flags" manually in the settings file, because it's supposed to be a list of options, not a string, as the other options. Perhaps "ld flags" was intended to let people extend "Ld Linker flags" manually via the settings file? Anyway, it doesn't work right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 13:31:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 13:31:57 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5MDU3OiBSZW1vdmUgL3Vzci9iaW4v4oCmIHJl?= =?utf-8?q?ferences?= In-Reply-To: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> References: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> Message-ID: <062.52055a12ba0f358b5b4bc703d7e9454d@haskell.org> #9057: Remove /usr/bin/? references -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: patch Priority: low | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D237 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D237 Comment: All fixed, except: * libraries are maintained on github * configure and autom4te.cache are created are by autotools -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 13:34:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 13:34:36 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.f1b6e8bb3d7916c6ec348d893ab127e8@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Yes, I looked into the cabal linker flags issue too, but forgot to mention it, sorry! Indeed there were several changes between 7.6.3 and 7.8 but cabal was not updated accordingly. (There was some minor fallout on the GHC side also, see #9614.) I think best is to update cabal to parse the new (7.8) fields if present and if not fall back on the old (7.6.3) fields. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 14:08:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 14:08:34 -0000 Subject: [GHC] #8026: DatatypeContexts should be fixed, not deprecated In-Reply-To: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> References: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> Message-ID: <059.29bdaaeebbe60a6e97a6fe5d85df82de@haskell.org> #8026: DatatypeContexts should be fixed, not deprecated -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gidyn): * status: closed => new * resolution: wontfix => Comment: See also [https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures #extra-constraints-wildcard Partial Type Signatures]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 14:12:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 14:12:16 -0000 Subject: [GHC] #9614: ghc --print-(gcc|ld)-linker-flags broken In-Reply-To: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> References: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> Message-ID: <062.789a2d31a0fca70dc564712ae57b1380@haskell.org> #9614: ghc --print-(gcc|ld)-linker-flags broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by duncan): Or possibly the real problem is that ghc changed the name of these fields unintentionally. Is/was there any reason for the change? When the change was made, did anyone realise that tools like Cabal rely on the names of the keys in the ghc --info key/value mapping? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 14:19:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 14:19:34 -0000 Subject: [GHC] #8026: DatatypeContexts should be fixed, not deprecated In-Reply-To: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> References: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> Message-ID: <059.bc5f98f99c6cd80bdcf3666a65780a17@haskell.org> #8026: DatatypeContexts should be fixed, not deprecated -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): It seems that those of us who have hacked on GHC in the past have a hard time understanding this proposal -- which, to me, looks either unsound (if implemented simply) or very complicated (adding the ability to ''return'' a constraint). If you want this to be considered, please write up a wiki page with detailed examples and types. Also, suggest how this feature should be implemented, in terms of a translation to GHC's core language. It currently all seems a little magical. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 14:19:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 14:19:42 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.335af8b5fd26a7645c53487419d3aa41@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by duncan): I don't mind if we have to update Cabal here. 7.8 is out and we can't undo that. But I'd rather that we had some test in place to look at the ghc --info output (and might as well cover the things mentioned in #9614 while we're at it), since we do have tools that rely on them and ghc should not change them unintentionally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 14:20:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 14:20:03 -0000 Subject: [GHC] #5248: Infer type context in a type signature In-Reply-To: <044.e950967fe115a78ceadcfe32cf485319@haskell.org> References: <044.e950967fe115a78ceadcfe32cf485319@haskell.org> Message-ID: <059.2530c61245e831b4e31526e54cd42c0d@haskell.org> #5248: Infer type context in a type signature -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: low | Version: 7.0.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: duplicate | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gidyn): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: This is now covered by [https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures#extra- constraints-wildcard Partial Type Signatures] for general type inference, and #8026 for the specific case of data types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 14:38:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 14:38:27 -0000 Subject: [GHC] #8026: DatatypeContexts should be fixed, not deprecated In-Reply-To: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> References: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> Message-ID: <059.e1820fbecbf6bdc76037cca0e04f50e6@haskell.org> #8026: DatatypeContexts should be fixed, not deprecated -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gidyn): Consider the first example {{{ data Eq a => Foo a = Foo a isEq :: Foo a -> Foo a -> Bool isEq (Foo x) (Foo y) = x == y }}} This won't compile, because `isEq` is missing `Eq a =>`. However, with [https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures#extra- constraints-wildcard Partial Type Signatures], we can write {{{ isEq :: _ => Foo a -> Foo a -> Bool }}} and GHC will infer the constraint. This proposal is requesting that whenever `DatatypeContexts` has been turned on, and a data type appears in a type signature, GHC will automatically infer the data type's context in the same way as it would for an extra-constraints wildcard. Is this clearer? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 14:49:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 14:49:00 -0000 Subject: [GHC] #8026: DatatypeContexts should be fixed, not deprecated In-Reply-To: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> References: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> Message-ID: <059.ce8ec697158ff2767ccbf9ea760b23f5@haskell.org> #8026: DatatypeContexts should be fixed, not deprecated -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gidyn): To emphasise: this proposal is '''not''' proposing a change to the type system. It is, similar to ?Partial Type Signatures, proposing a new use for GHC's existing type inference capabilities. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 14:55:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 14:55:27 -0000 Subject: [GHC] #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' In-Reply-To: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> References: <049.47e45d388300995b3a92374ebfa9dcb0@haskell.org> Message-ID: <064.86f53858de0792e2ebe2b1e74edab27a@haskell.org> #9589: Building GHC as a cross-compiler for armhf fails with undefined reference to `dlopen', `dlerror', `dlsym' -------------------------------------+------------------------------------- Reporter: jpmasseria | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jpmasseria): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 15:33:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 15:33:16 -0000 Subject: [GHC] #9614: ghc --print-(gcc|ld)-linker-flags broken In-Reply-To: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> References: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> Message-ID: <062.01d5fac1d1715e9ec415851185b15acb@haskell.org> #9614: ghc --print-(gcc|ld)-linker-flags broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): I think it was decided here: https://ghc.haskell.org/trac/ghc/ticket/4862#comment:12 and I think it wasn't completely finished, despite the closed ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 15:34:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 15:34:09 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.be66143d3b6daf9dc302c5a9d91334ad@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: 9614 GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * blockedby: => 9614 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 15:47:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 15:47:52 -0000 Subject: [GHC] #9614: ghc --print-(gcc|ld)-linker-flags broken In-Reply-To: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> References: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> Message-ID: <062.e646a91d6d77fb6a3448dfdfdfc64635@haskell.org> #9614: ghc --print-(gcc|ld)-linker-flags broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 9421 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): Forgive my intrusion here, but this seems like another side effect of not having a true type-safe API between GHC and Cabal. We are bound to rely on test cases for things that, seems to me, could get a hand from a minimal set of types in a standalone package shared between Cabal and GHC. If kept to a minimum, this package should change as often as there is a real change in the API between GHC and Cabal and no more than that. If we had such API, this problem would either show up when trying to build GHC (if the above change was really a mistake) or show up when compiling Cabal since the API was changed to accommodate the changed flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 16:09:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 16:09:06 -0000 Subject: [GHC] #8026: DatatypeContexts should be fixed, not deprecated In-Reply-To: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> References: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> Message-ID: <059.57d95264e6f43101c5cfd146d39a526d@haskell.org> #8026: DatatypeContexts should be fixed, not deprecated -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): This proposal ''does'' propose a change to the type system, as it proposes a change to the set of well-typed programs. The same is true of partial type signatures. Type inference is an algorithm that implements a way to enforce the constraints of a type system. Your example is clear for that simple situation. But, Haskell's type system is not that simple! For example: {{{ data Eq a => HasEq a = MkHasEq a deriving Typeable data Show a => HasShow a = MkHasShow a a :: Maybe (HasEq a) -> Maybe (HasEq a) -> Bool a (Just x) (Just y) = x == y a _ _ = Nothing b :: Either (HasEq a) (HasShow a) -> String -- what constraints are used here??? b (Left x) = show (x == x) b (Right x) = show x c :: Proxy (HasEq a) -> () -- what constraints are used here??? c _ = () data Dynamic = forall a. Typeable a => MkDyn a d :: Dynamic -> Maybe Bool d (MkDyn y) | Just (MkHasEq z) <- cast y = Just (z == z) -- where does the Eq constraint come from?? d _ = Nothing }}} Your examples seem to address specific, easy cases. But, we need to consider all the wide range of compositions with other Haskell features! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 18:26:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 18:26:00 -0000 Subject: [GHC] #9625: ghc: panic using --enable-executable-dynamic Message-ID: <051.41ace47270d90cc9e836ab3706638147@haskell.org> #9625: ghc: panic using --enable-executable-dynamic -------------------------------------+------------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (from: https://github.com/haskell/cabal/issues/2039) Using --enable-executable-dynamic leads to a ghc panic. Reproduction steps: 1. clone https://github.com/coreyoconnor/executable-dynamic-issue 2. cabal configure --enable-tests --enable-executable-dynamic 3. cabal test Expected results: Test executes and passes. Actual results: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64 -unknown-linux): Don't understand library name verify-foo }}} Actual results varies based on the name of "verify-foo" test suite. Other names tried: "verifyFoo", "VerifyFoo". All of which also fail. Removing "--enable-executable-dynamic" results in a pass regardless of test suite name. Reproduced on GHC 7.8.2, GHC 7.8.3, Cabal 1.18, Cabal 1.20. Ubuntu. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 20:13:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 20:13:42 -0000 Subject: [GHC] #9626: Test command lines munged on Windows when running on msys Python Message-ID: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> #9626: Test command lines munged on Windows when running on msys Python -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- On Windows, the test runner works fine if run under Windows-native Python, but fails with the msys Python because of the heuristic transformations that msys applies to all binary invocations of non-msys binaries (such as timeout.exe) by msys binaries (such as python). This is relatively easy to sidestep by going through /usr/bin/cmd in msys which sidesteps the argument munging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 20:15:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 20:15:32 -0000 Subject: [GHC] #9626: Test command lines munged on Windows when running on msys Python In-Reply-To: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> References: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> Message-ID: <060.5621fbde4096c4599896c045e64df60f@haskell.org> #9626: Test command lines munged on Windows when running on msys Python -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): Example error when run under msys2 Python: =====> gadt2(optasm) 2 of 76 [0, 5, 0] cd . && 'C:/msys64/home/gintas/ghc3/inplace/bin/ghc-stage2.exe' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o gadt2 gadt2.hs -O -fasm >gadt2.comp.stderr 2>&1 Compile failed (status 32512) errors were: sh: C;C:\msys64\msys64\home\gintas\ghc3\inplace\bin\ghc-stage2.exe: No such file or directory -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 21:26:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 21:26:18 -0000 Subject: [GHC] #9626: Test command lines munged on Windows when running on msys Python In-Reply-To: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> References: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> Message-ID: <060.d9664f7d4fa21fd2a51b325f78b6a561@haskell.org> #9626: Test command lines munged on Windows when running on msys Python -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 22 21:42:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Sep 2014 21:42:07 -0000 Subject: [GHC] #8026: DatatypeContexts should be fixed, not deprecated In-Reply-To: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> References: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> Message-ID: <059.00d46925a99cbeb7d75ba3c27cd7897f@haskell.org> #8026: DatatypeContexts should be fixed, not deprecated -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by yokto): Ok I'm not an expert in type theory or anything but let me try to explain based on your example. I don't know how this relates to type theory or if it is sound but it covers all the cases I could think of. {{{data Eq a => HasEq a = MkHasEq a}}} == Deriving Types == How can you get a value of type {{{HasEq a}}}. 1. Using a Constructor (also in a pattern): Use the same trick as with GADTs? Just make the type signature of the constructor {{{(Eq a) => a -> HasEq a}}} 2. Explicit type signature {{{(undefined :: HasEq a)}}}: Add the constraint {{{(Eq a)}}} to all explicit type signatures containing HasEq a. If you have more variables {{{HasEq (Either a b)}}} use the inner most forall in which one of the variables is bound {{{ (forall a. HasEq (Either a b) -> c) -> c -> b }}} becomes {{{ (forall a. (Eq (Either a b)) => HasEq (Either a b) -> c) -> c -> b }}} 3. Functions in modules without this extension. Maybe it's possible to add the contexts when the functions are imported. I don't know. == Hiding Types. == This doesn't even really concern haskell anymore. It's just a question of how you can tell ghci or haddock that it doesn't need to show the contexts that were derived. == Examples == Example1: {{{ a :: Maybe (HasEq a) -> Maybe (HasEq a) -> Bool a (Just x) (Just y) = x == y a _ _ = Nothing }}} according to rule 2. gets translated to. {{{a :: (Eq a) => Maybe (HasEq a) -> Maybe (HasEq a) -> Bool}}} Example2: {{{ b :: Either (HasEq a) (HasShow a) -> String -- what constraints are used here??? b (Left x) = show (x == x) b (Right x) = show x }}} according to rule 2. gets translated to. {{{ b :: (Eq a, Show a) => Either (HasEq a) (HasShow a) -> String }}} Example3: {{{ c :: Proxy (HasEq a) -> () -- what constraints are used here??? c _ = () }}} according to rule 2. gets translated to. Though I don't really know what Proxy does. {{{ c :: (Eq a) => Proxy (HasEq a) -> () }}} {{{ d :: Dynamic -> Maybe Bool d (MkDyn y) | Just (MkHasEq z) <- cast y = Just (z == z) -- where does the Eq constraint come from?? d _ = Nothing }}} according to rule 1. The Eq quality constraint gets set because of the use of the constructor. I'm not sure how to write this in terms of types but it works for GADTs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 07:23:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 07:23:57 -0000 Subject: [GHC] #8026: DatatypeContexts should be fixed, not deprecated In-Reply-To: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> References: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> Message-ID: <059.06620743554cb8fb8a5d350695420f2b@haskell.org> #8026: DatatypeContexts should be fixed, not deprecated -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gidyn): I think we actually have 2 implementation proposals here: - tokyo's rules add type constraints, whenever the data type appears in an explicit type signature or when the constructor is used - use regular type inference The second implementation would give different results for `c` and `d`: {{{ c :: Proxy (HasEq a) -> () -- what constraints are used here??? c _ = () }}} No type constraint is added, because none is inferred by the definition of `c`. {{{ data Dynamic = forall a. Typeable a => MkDyn a d :: Dynamic -> Maybe Bool d (MkDyn y) | Just (MkHasEq z) <- cast y = Just (z == z) -- where does the Eq constraint come from?? d _ = Nothing }}} `DatatypeContexts` wouldn't have any effect in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 07:58:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 07:58:13 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.338771d35ee282a285ff066f6e56781d@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: ekmett (added) Comment: Just a thought, what about: {{{#!hs atomicModifyIORef' ref f = evaluate =<< atomicModifyIORef ref (\a -> case f a of v@(!a',_) -> v) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 09:12:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 09:12:56 -0000 Subject: [GHC] #2273: inlining defeats seq In-Reply-To: <044.9c3223a55b4d3223b10ccf35be7e7d4f@haskell.org> References: <044.9c3223a55b4d3223b10ccf35be7e7d4f@haskell.org> Message-ID: <059.6866163ff22e6e855b4495c642c65d7f@haskell.org> #2273: inlining defeats seq -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): In [changeset:"970816ac0028f2f42ac4140d29e2f0dfe0e9af3e/ghc"] (Simon Marlow, September 2009): {{{ #!CommitTicketReference repository="ghc" revision="970816ac0028f2f42ac4140d29e2f0dfe0e9af3e" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 09:33:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 09:33:36 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs In-Reply-To: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> References: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> Message-ID: <066.542d223c27382cc5d64bd3aacbf1d7fd@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: patch Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: InstanceSigs (Type checker) | TypeFamilies Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm sorry about being slow to reply -- utterly swamped. > 2. 'tcSubType' does not generate errors, just postponed > constraints, which are checked later in a clean-up phase. Thus, I do > not get an error now I could handle, but the error is generated later > during the constraint solving phase, where I do not have a handler in place. This is dead right, and I think it's a huge strength of GHC's current type inference mechanism. Essentially all type error messages are generated in `TcErrors`, not in places scattered over the compiler. This is not a "clean-up phase". It is ''the'' place that type errors are generated. For `tcSubType`, the way to control your error messages is through the `CtOrigin` and `UserTypeCtxt` passed to `tcSubType`. The `UserTypeCtx`t is attached (via the ic_info field of `Implication`) to the implication constraint generated by the `tcSubType`. If you want, you can add an extra constructor to `UserTypeCtxt`. The `CtOrigin` is attached to the instantiated constraints generated by the sub-type check. Both are accessible to the error-message generation in `TcErrors`. In short, instead of catching the error(s) ''now'', GHC just attaches enough information to the constraints that you can generate a good error message later. I hope that is of some help. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 09:37:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 09:37:40 -0000 Subject: [GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. In-Reply-To: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> References: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> Message-ID: <058.bd58ad7284fa081bd499d657287e59ee@haskell.org> #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: type family, Resolution: | ambiguity check Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: #9607 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:7 oleg]: > I have played with giving type annotations for quite a long time, without success. .... > I wonder what wrong could happen if we just assume injectivity in such cases. If I understand simonpj correctly, he would like to make sure it is possible to give explicit signatures ''first'', even if those would be nasty to write and/or read, and only add inference rules for such afterwards. This sounds reasonable to me, but I'm no expert. Maybe this will finally push him to implement the explicit type applications he's mentioned in the past? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 10:04:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 10:04:59 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.2dd09cf0b59dc3cc37940621fdd88db9@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:9 simonpj]: > Patch coming any ETA on that patch? It's blocking a few things right now... :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 10:26:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 10:26:32 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.73faadf0a14a16c3ffee6d28da44bfc8@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5fa6e75960b3dddbc72c35eb3fc0f2759215dfbb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5fa6e75960b3dddbc72c35eb3fc0f2759215dfbb" Ensure that loop breakers are computed when glomming This patch fixes Trac #9583, a loop in the simplifier. I thought this was going to be very complicated but it turned out to be very simple! The occurrence analyser does something called "glomming" if the application of imported RULES means that something that didn't look recursive becomes recursive. See `Note [Glomming]` in `OccurAnal`. Under these circumstances we group all the top-level bindings into a single massive `Rec`. But, crucially, I failed to repeat the occurrence analysis on this glommed set of bindings. That means that we weren't establishing the right loop breakers (indeed there were no loop breakers whatsoever), and that led immediately to the loop. The only surprising this is that it didn't happen before. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 10:27:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 10:27:42 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.beaeac60485f307277c1c02f9f579ec2@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I've just pushed it. I'm getting a failure on `perf/compiler/T783`, but as usual I'm uncertain about whether the patch is the culprit or not. I suspect not, so since it's a blocker I'm pushing it anyway. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 11:09:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 11:09:14 -0000 Subject: [GHC] #9565: T3500b exhaust simplifier ticks (loops?) on WAY=optasm In-Reply-To: <045.21253a4eab836dbd85b1b13d4815a773@haskell.org> References: <045.21253a4eab836dbd85b1b13d4815a773@haskell.org> Message-ID: <060.5509a430ed8becbd8eb1ca4c6dbb50ef@haskell.org> #9565: T3500b exhaust simplifier ticks (loops?) on WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: T3500b | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"01906c7399301e4f69959ecbd3b0d8bee5d5ef70/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="01906c7399301e4f69959ecbd3b0d8bee5d5ef70" Test Trac #9565 and #9583 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 11:09:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 11:09:14 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.1241ff757c4791b060839bf6d0cd5ed4@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"01906c7399301e4f69959ecbd3b0d8bee5d5ef70/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="01906c7399301e4f69959ecbd3b0d8bee5d5ef70" Test Trac #9565 and #9583 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 11:11:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 11:11:13 -0000 Subject: [GHC] #9565: T3500b exhaust simplifier ticks (loops?) on WAY=optasm In-Reply-To: <045.21253a4eab836dbd85b1b13d4815a773@haskell.org> References: <045.21253a4eab836dbd85b1b13d4815a773@haskell.org> Message-ID: <060.427561a84df5cacda6f9cfe284cdc661@haskell.org> #9565: T3500b exhaust simplifier ticks (loops?) on WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | simplCore/should_compile/T9565 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: T3500b => simplCore/should_compile/T9565 * resolution: => fixed Comment: I'm happy to say that this is fixed by the same patch as #9583. I've added a separate test case (compile only) since the purpose is different to the (identical) test for #3500. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 11:12:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 11:12:39 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.f4905a49d2b564cebc5da24b5b376498@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: dreixel (added) Comment: Perhaps someone can confirm that Cabal is ok, and then close. Pedro: the "deriving Binary" stuff still generates a gargantuan quantity of code! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 11:56:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 11:56:24 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.eb9b6746e7d7ad0eb16eda90a514ba61@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:12 simonpj]: > I've just pushed it. I'm getting a failure on `perf/compiler/T783`, but as usual I'm uncertain about whether the patch is the culprit or not. I suspect not, so since it's a blocker I'm pushing it anyway. fwiw, Phab:harbormaster/build/952 built just fine (but that's for Linux/x86_64 thresholds) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 12:10:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 12:10:45 -0000 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@haskell.org> References: <051.9654be8110cd7a09257c98a211221fb3@haskell.org> Message-ID: <066.acb47e2b48a8cda765caf944f8ec2e89@haskell.org> #3231: Permission denied error with runProcess/openFile -------------------------------------+------------------------------------- Reporter: | Owner: simonmar NeilMitchell | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 6.10.4 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by yugr): * cc: tetra2005@?, hvr, ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 13:11:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 13:11:56 -0000 Subject: [GHC] #9249: Link to "latest" user's guide In-Reply-To: <047.de05e08954a03649b76e01617284c75d@haskell.org> References: <047.de05e08954a03649b76e01617284c75d@haskell.org> Message-ID: <062.68df04c3abe75fdbeb2da1e5fe1148b3@haskell.org> #9249: Link to "latest" user's guide -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.8.2 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Similar issues for hackage: https://github.com/haskell/cabal/issues/750 https://github.com/haskell/hackage-server/issues/61#issuecomment-24742342 https://github.com/haskell/hackage-server/issues/198 There it is suggested to use canonical urls: https://support.google.com/webmasters/answer/139066?rd=1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 13:28:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 13:28:48 -0000 Subject: [GHC] #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 In-Reply-To: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> References: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> Message-ID: <059.5e4fda6a84054e5fd6e9acc5c7941734@haskell.org> #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: infoneeded => closed * resolution: => fixed Comment: Looks fixed now after a quick attempt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 13:30:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 13:30:33 -0000 Subject: [GHC] #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 In-Reply-To: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> References: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> Message-ID: <065.f022fe8bbb7f1f79f4d75bed250bc2c9@haskell.org> #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 -------------------------------------+------------------------------------- Reporter: | Owner: MichalGajda | Status: closed Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.1-rc2 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #7068, #7898 time crash | Test Case: cabal | install hPDB | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: This looks like it's now fixed in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 13:32:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 13:32:23 -0000 Subject: [GHC] #8836: ghc 7.6.3 and 7.4.2 hang on -O2 In-Reply-To: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> References: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> Message-ID: <061.598bb7862a3c66be5a41cb0b630b436b@haskell.org> #8836: ghc 7.6.3 and 7.4.2 hang on -O2 -------------------------------------+------------------------------------- Reporter: tsuraan | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thoughtpolice): I believe this is fixed in HEAD after a quick attempt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 13:32:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 13:32:30 -0000 Subject: [GHC] #8836: ghc 7.6.3 and 7.4.2 hang on -O2 In-Reply-To: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> References: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> Message-ID: <061.5b3a6889435a15916e472d7581253036@haskell.org> #8836: ghc 7.6.3 and 7.4.2 hang on -O2 -------------------------------------+------------------------------------- Reporter: tsuraan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 13:45:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 13:45:34 -0000 Subject: [GHC] #2034: In FilePath, current directory should be ".", not "" In-Reply-To: <044.ce5a2afddc700a95979f00cd58ea4c17@haskell.org> References: <044.ce5a2afddc700a95979f00cd58ea4c17@haskell.org> Message-ID: <059.bfc493d44714b090cb6c37000da97fd2@haskell.org> #2034: In FilePath, current directory should be ".", not "" --------------------------------------+--------------------------------- Reporter: igloo | Owner: neil Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | --------------------------------------+--------------------------------- Comment (by Austin Seipp ): In [changeset:"2a743bbddd4de41a77af9b83ec4720cd013292cf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2a743bbddd4de41a77af9b83ec4720cd013292cf" Delete hack when takeDirectory returns "" Summary: Since commits 8fe1f8 and bb6731 in the filepath packages (ticket #2034, closed in 2010), takeDirectory "foo" returns ".", and not "", so this check is no longer needed. Other commits: * Remove trailing whitespace * Update comments for #2278 Test Plan: harbormaster Reviewers: austin Reviewed By: austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D213 GHC Trac Issues: #2034 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 13:45:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 13:45:34 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5MDU3OiBSZW1vdmUgL3Vzci9iaW4v4oCmIHJl?= =?utf-8?q?ferences?= In-Reply-To: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> References: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> Message-ID: <062.b36b49d99e7af353849b96f7a114402c@haskell.org> #9057: Remove /usr/bin/? references -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: patch Priority: low | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D237 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"d5e4874833054f1789289c433be292ae3e9bd7d0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d5e4874833054f1789289c433be292ae3e9bd7d0" Change all hashbangs to /usr/bin/env (#9057) Summary: ``` git grep -l '#!' | xargs sed -i 's|#!.*/bin/\([^ ]*\)$|#!/usr/bin/env \1|' ``` and some manual tweaking Test Plan: harbormaster Reviewers: austin Subscribers: hvr, simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D237 GHC Trac Issues: #9057 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 13:45:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 13:45:34 -0000 Subject: [GHC] #2278: Inconsistent behaviour between -odir and -hidir options In-Reply-To: <044.da2157b8bb277561bb6fe2b75576c141@haskell.org> References: <044.da2157b8bb277561bb6fe2b75576c141@haskell.org> Message-ID: <059.a3aa27edef462e4fe03bfa7d67e87890@haskell.org> #2278: Inconsistent behaviour between -odir and -hidir options -----------------------------+---------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Difficulty: Unknown | Test Case: -----------------------------+---------------------------- Comment (by Austin Seipp ): In [changeset:"2a743bbddd4de41a77af9b83ec4720cd013292cf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2a743bbddd4de41a77af9b83ec4720cd013292cf" Delete hack when takeDirectory returns "" Summary: Since commits 8fe1f8 and bb6731 in the filepath packages (ticket #2034, closed in 2010), takeDirectory "foo" returns ".", and not "", so this check is no longer needed. Other commits: * Remove trailing whitespace * Update comments for #2278 Test Plan: harbormaster Reviewers: austin Reviewed By: austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D213 GHC Trac Issues: #2034 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 14:14:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 14:14:48 -0000 Subject: [GHC] #9627: Type error with functional dependencies Message-ID: <047.4796ed7275cf4f912175b5a495799bce@haskell.org> #9627: Type error with functional dependencies -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The attached file should compile. The types T1, T2, and T3 are all equivalent types (T1 and T2 normalize to T3), but with foo::T1 and bar::T2 there is a type error. Rewriting the example using type families instead of FD makes it work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 17:41:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 17:41:15 -0000 Subject: [GHC] #2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` In-Reply-To: <043.429d5e175a90219c9682c6f3937cb586@haskell.org> References: <043.429d5e175a90219c9682c6f3937cb586@haskell.org> Message-ID: <058.e0e3f364b100a29470b46934ee2c562d@haskell.org> #2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` -------------------------------------+------------------------------------- Reporter: jsnx | Owner: mjg Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.8.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr, ekmett (added) Comment: Link to [https://github.com/haskell/cabal/blob/master/Cabal/Distribution/System.hs Distribution.System]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 17:49:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 17:49:00 -0000 Subject: [GHC] #8253: example "Core syntax" is ancient In-Reply-To: <047.c3b31fabaa8a2840d3e512d5592d8b22@haskell.org> References: <047.c3b31fabaa8a2840d3e512d5592d8b22@haskell.org> Message-ID: <062.5a80f7614f2d77cd72fdb8c35483845f@haskell.org> #8253: example "Core syntax" is ancient -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:1 afleck]: > Wow, that's very different, the same comments don't even apply. Is it necessary to re-comment the code? > > I've attached a log of the output. If you understand that output, could you indeed add some comments. Then we can update the documentation and close this ticket. The current version is not very helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 18:34:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 18:34:04 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions Message-ID: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Two different kinds of annotation are proposed to be added to HsSyn 1. Additional elements to explictly track the location of all syntactic elements not currently tracked. In particular, locations of reserved words and punctuation. 2. A top-level type parameter that allows a tool-writer to thread an application-specific annotation through the syntax tree. These two could potentially be merged, if the default annotation parameter is capable of tracking the first category of information. Discussion of the feature is at GhcAstAnnotations -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 18:43:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 18:43:33 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.9bffd555987c74c45bfb592f8f0c4f60@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 18:52:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 18:52:57 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.9064b321f5e7682c1cfaff79c5b4c3ba@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 19:28:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 19:28:20 -0000 Subject: [GHC] #9629: GHC panic while installing purescript Message-ID: <049.a4dae3fb58190738d63c639d40122bed@haskell.org> #9629: GHC panic while installing purescript -------------------------------------+------------------------------------- Reporter: jlburkhead | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ $ cabal install purescript [1 of 1] Compiling Main ( /tmp/purescript-0.5.6.2-11475/purescript-0.5.6.2/dist/setup/setup.hs, /tmp/purescript-0.5.6.2-11475/purescript-0.5.6.2/dist/setup/Main.o ) Linking /tmp/purescript-0.5.6.2-11475/purescript-0.5.6.2/dist/setup/setup ... Configuring purescript-0.5.6.2... Building purescript-0.5.6.2... Preprocessing library purescript-0.5.6.2... [ 1 of 53] Compiling Language.PureScript.Parser.State ( src/Language/PureScript/Parser/State.hs, dist/build/Language/PureScript/Parser/State.o ) ... [53 of 53] Compiling Language.PureScript ( src/Language/PureScript.hs, dist/build/Language/PureScript.o ) In-place registering purescript-0.5.6.2... Preprocessing executable 'psc' for purescript-0.5.6.2... [1 of 2] Compiling Paths_purescript ( dist/build/autogen/Paths_purescript.hs, dist/build/psc/psc- tmp/Paths_purescript.o ) [2 of 2] Compiling Main ( psc/Main.hs, dist/build/psc/psc- tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-unknown-linux): tyThingTyCon Data constructor `purescript-0.5.6.2:Language.PureScript.Options.Compile{d r21e}' Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Failed to install purescript-0.5.6.2 cabal: Error: some packages failed to install: purescript-0.5.6.2 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 19:32:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 19:32:42 -0000 Subject: [GHC] #9629: GHC panic while installing purescript In-Reply-To: <049.a4dae3fb58190738d63c639d40122bed@haskell.org> References: <049.a4dae3fb58190738d63c639d40122bed@haskell.org> Message-ID: <064.a07dcd633cc196eb4100bb9e451d7e1c@haskell.org> #9629: GHC panic while installing purescript -------------------------------------+------------------------------------- Reporter: jlburkhead | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Does this happen with 7.8 too? I'm afraid we are unlikely to fix 7.4.1. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 20:01:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 20:01:44 -0000 Subject: [GHC] #9629: GHC panic while installing purescript In-Reply-To: <049.a4dae3fb58190738d63c639d40122bed@haskell.org> References: <049.a4dae3fb58190738d63c639d40122bed@haskell.org> Message-ID: <064.9b229268bba9776c392abfeecb4887ed@haskell.org> #9629: GHC panic while installing purescript -------------------------------------+------------------------------------- Reporter: jlburkhead | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jlburkhead): Works fine with 7.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 20:08:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 20:08:45 -0000 Subject: [GHC] #9629: GHC panic while installing purescript In-Reply-To: <049.a4dae3fb58190738d63c639d40122bed@haskell.org> References: <049.a4dae3fb58190738d63c639d40122bed@haskell.org> Message-ID: <064.069c8750f4b8389a9c12a0813bd73c6d@haskell.org> #9629: GHC panic while installing purescript -------------------------------------+------------------------------------- Reporter: jlburkhead | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * status: new => closed * resolution: => fixed Comment: yup, pure script builds fine in ghc 7.8.3, and supporting older GHC's is totally up the the pure script maintainer. closing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 20:22:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 20:22:19 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.4d3aa43eab72734af29dcd1f77cec66e@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Alan writes (in email): I have decided to first tackle adding a type parameter to the entire AST, so that tool writers can add custom information as required. My first stab at this is to do is as follows {{{ data HsModule r name = HsModule { ann :: r, -- ^ Annotation for external tool writers hsmodName :: Maybe (Located ModuleName), -- ^ @Nothing@: \"module X where\" is omitted (in which case the next -- field is Nothing too) hsmodExports :: Maybe [LIE name], .... }}} Salient points 1. It comes as the first type parameter, and is called r 2. It gets added as the first field of the syntax element 3. It is always called ann Before undertaking this particular change, I would appreciate some feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 20:25:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 20:25:31 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.903db116b4ed3999243279dcbd5fd271@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Whoa! There appear to be two quite separate things going on here: * In [wiki:GhcAstAnnotations] the issue is attaching a `SrcSpan` to keywords * In comment:1 the issue appears to be about attaching an annotation of client-specified type to every node in the tree. These seem quite orthogonal to me. For the latter I would suggest looking at the `Located` type, instead of what you suggest in comment:1. The `Located` type is wrapped around almost every node in the tree, and if you want to add some ubiquitous annotation type, it would be the place to do so. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 20:32:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 20:32:06 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.fc10fbbd4ec5d3f782c678d95eca9956@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): Is this a linux only bug? I just built compdata-0.9 in a sandbox on my mac and I didn't encounter this problem. I used my own build of GHC 7.8.3 on OS X 10.9 Has anyone reproduced this issue on linux with GHC 7.8.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 20:38:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 20:38:34 -0000 Subject: [GHC] #9627: Type error with functional dependencies In-Reply-To: <047.4796ed7275cf4f912175b5a495799bce@haskell.org> References: <047.4796ed7275cf4f912175b5a495799bce@haskell.org> Message-ID: <062.3f6a37a10a0421d68a35da0da10e697e@haskell.org> #9627: Type error with functional dependencies -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Indeed. Here is a more direct example: {{{ class C a b | a -> b instance C Int Bool f :: C Int b => b -> Bool f x = x }}} From which we get {{{ Foo.hs:9:7: Could not deduce (b ~ Bool) from the context (C Int b) }}} Remember that GHC elaborates the program into System FC, generating evidence. * For type families, we know how to elaborate the program with proper, abstractable evidence in System FC * For functional dependencies I have no clue what evidence might look like. All GHC does (and all Hugs does) is to generate extra unification constraints; think of them as hints to guide the choice of how to instantiate unification variables. In the exmaple above there are no unification variables, so these hints do nothing, and the program is rejected. It's the same with your larger example. If someone can explain how to elaborate functional dependencies into well- typed evidence in System FC, that would be good. My inability to do so was one of the reasons we developed type families and System FC in the first place. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 20:39:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 20:39:27 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.defa0f402462061066405bca6cb44008@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by alanz): Firstly, I agree that this is in fact two orthogonal things, but I think it is good to discuss them together because some potential solutions could couple them together. `Located` is something that I considered for the annotation parameter, but I am concerned that it is so baked in to everything else that if it changed it would cause other unforeseen problems. In order to use it in this way it would have to become a parameter to the AST too, effectively replacing all instances of `Located` with `GenLocated`. Reference: {{{ data GenLocated l e = L l e deriving (Eq, Ord, Typeable, Data) type Located e = GenLocated SrcSpan e }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 21:54:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 21:54:01 -0000 Subject: [GHC] #7913: Argument order not preserved by nubBy In-Reply-To: <046.71badb87ed4d077930b6019bd00cb4be@haskell.org> References: <046.71badb87ed4d077930b6019bd00cb4be@haskell.org> Message-ID: <061.bb76091790faa2b198bb1da10c8730b9@haskell.org> #7913: Argument order not preserved by nubBy -------------------------------------+------------------------------------- Reporter: paullik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: nubBy Operating System: Linux | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Library proposal for the 'still easy' solution: http://www.haskell.org/pipermail/libraries/2014-September/023776.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 21:59:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 21:59:35 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.952227a67c5fde12407779a20863e75a@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: ? Component: | Version: 6.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr, ekmett (added) Comment: Proposal to remove versionTags: http://www.haskell.org/pipermail/libraries/2014-September/023777.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 22:06:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 22:06:44 -0000 Subject: [GHC] #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# In-Reply-To: <045.5cc829a852152f43b89d9843483d1a41@haskell.org> References: <045.5cc829a852152f43b89d9843483d1a41@haskell.org> Message-ID: <060.57973811f7ceed5d3290a6628cf5045c@haskell.org> #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# -------------------------------------+------------------------------------- Reporter: malosh | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 6.12.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jystic): * cc: jystic@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 22:28:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 22:28:06 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.b5025d1275a7d659eef8fea2544b38ad@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 4213 | Differential Revisions: Phab:D155 | -------------------------------------+------------------------------------- Comment (by jrp): To give this a bump, one possible test for this would be {{{cabal install diagrams}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 22:36:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 22:36:04 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5MDU3OiBSZW1vdmUgL3Vzci9iaW4v4oCmIHJl?= =?utf-8?q?ferences?= In-Reply-To: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> References: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> Message-ID: <062.7c663292fbfc04223202c46b80418e49@haskell.org> #9057: Remove /usr/bin/? references -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: closed Priority: low | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D237 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 23:29:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 23:29:28 -0000 Subject: [GHC] #8026: DatatypeContexts should be fixed, not deprecated In-Reply-To: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> References: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> Message-ID: <059.5c41c3637729728a4408a8f7930c99ca@haskell.org> #8026: DatatypeContexts should be fixed, not deprecated -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by yokto): I just found an other interesting realworld example that could profit from this extension. Consider the vector package. All type signature look something like this. {{{read :: PrimMonad m => MVector (PrimState m) a -> Int -> m a}}} Horrible to read, right. With this issue fixed you could put the context on MVector {{{data (PrimMonad m, PrimState m ~ s) => MVector s a = MVector !Int !Int !(MutableArray s a)}}} and the type signatures could look like this {{{read :: MVector s a -> Int -> m a}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 23 23:38:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Sep 2014 23:38:15 -0000 Subject: [GHC] #9550: Add uncons to Data.List In-Reply-To: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> References: <045.348edbe99a03c503bb7acb6834c665d9@haskell.org> Message-ID: <060.36710cdae7f8544c28dcc5f58944d371@haskell.org> #9550: Add uncons to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D195 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 05:08:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 05:08:20 -0000 Subject: [GHC] #5556: Support pin-changing on ByteArray#s In-Reply-To: <046.1b81478cf84dfba9336774f0fe7553f1@haskell.org> References: <046.1b81478cf84dfba9336774f0fe7553f1@haskell.org> Message-ID: <061.3a8669e44cae597beae45863f886c4c9@haskell.org> #5556: Support pin-changing on ByteArray#s -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jystic): * cc: jystic@? (added) * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 07:48:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 07:48:08 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.ba773f65395e7ec872fdbca0a382ccfa@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:14 simonpj]: > Perhaps someone can confirm that Cabal is ok, and then close. > > Pedro: the "deriving Binary" stuff still generates a gargantuan quantity of code! Compiling Cabal within the GHC tree is not really ok (see comments in Phab:D183). It does compile, but it takes *several* minutes as well as massive amount of memory (over 50% of the 4GiB mem available in the buildbot, causing it to fail w/ an out-of-mem exception since we build mit CPUS=4) to when trying to produce the `libraries/Cabal/Cabal/dist- install/build/Language/Haskell/Extension.o` module with `ghc-stage1` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 07:52:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 07:52:17 -0000 Subject: [GHC] #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build In-Reply-To: <045.67b198827318e5a03441f1825701405b@haskell.org> References: <045.67b198827318e5a03441f1825701405b@haskell.org> Message-ID: <060.f1ea0b895193ba661000b01f3bcc9a0c@haskell.org> #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by quantheory): I have done a little bit more on this, so can elaborate. > Unclear. `wrap . unwrap = id` seems to strong?I don't ''think'' any non- trivial wrappers satisfy it. I agree. From what I've seen so far, `wrap . unwrap = id` only fits in cases where `build`/`foldr` already worked in the first place. > What makes a producer valid is not so clear, but yes, it seems less complicated than the consumer side. > [...] > This implementation fails for some reason you haven't tested. My hope had been that if the definition of a good consumer could be nailed down well enough, then producers would be trivial. But it's looking increasingly difficult to get this right. I did find the issues with scanl and reverse; in fact, even after fixing `reverse . scanl f z $ xs`, I still had issues with `reverse . scanl f z . reverse $ xs`. But I did eventually fix both cases with this change: https://github.com/quantheory/ww- fusion/commit/74618328c34572270154dbd93eb441f448760e0e It seems that, on top of needing `wrap . unwrap $ cons = cons`, if you have multiple layers of wrapper, there are more conditions needed to ensure that one wrapper doesn't break an invariant relied upon by an underlying wrapper. My first attempted fix for scanl used `k` twice, attempting to throw away the result in one case. But it turned out that, when combined with `reverse`, the extra `k b` would be moved to where it could insert extra, wrong values into the stream. This is why, in the commit linked above, I use `n` in `scanlWrap`: presumably `n` should never add new values. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 08:19:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 08:19:41 -0000 Subject: [GHC] #8070: Use a captcha for trac registrations In-Reply-To: <044.f2a36852e2772074b1987ebd0c5e0ae0@haskell.org> References: <044.f2a36852e2772074b1987ebd0c5e0ae0@haskell.org> Message-ID: <059.a7abf60c5090e932e731cbd22f8053c0@haskell.org> #8070: Use a captcha for trac registrations -------------------------------------+------------------------------------- Reporter: igloo | Owner: hvr Type: task | Status: closed Priority: high | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: trac admin Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 08:22:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 08:22:40 -0000 Subject: [GHC] #8897: Can't change "Full Name" in preferences In-Reply-To: <050.cac5fdb9d34ae50c72ea407a1870d09e@haskell.org> References: <050.cac5fdb9d34ae50c72ea407a1870d09e@haskell.org> Message-ID: <065.e8807a059d3d635b4fdf2b510dbaf296@haskell.org> #8897: Can't change "Full Name" in preferences -------------------------------------+------------------------------------- Reporter: | Owner: hvr novadenizen | Status: closed Type: bug | Milestone: Priority: lowest | Version: Component: Trac & Git | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 08:33:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 08:33:41 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.3014247db841b7e7e56c9ecc95ed5d93@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Well this ticket was about a bug in GHC that meant it really didn't compile *at all*. Now, from what you say, it does. But there may still be a problem with the amount of code that `deriving Binary` generates (hence copying Pedro), perhaps due to nested tuples (which might be helped by the new SOP approach) or perhaps due to over-enthusiastic INLINE pragmas. In any case, I don't think there's a bug in GHC any more. But I'll leave this ticket open in the hope that we may make progress on the `deriving Binary` question. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 08:53:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 08:53:42 -0000 Subject: [GHC] #8026: DatatypeContexts should be fixed, not deprecated In-Reply-To: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> References: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> Message-ID: <059.88be63644912aeb486acbf40cbc01f2d@haskell.org> #8026: DatatypeContexts should be fixed, not deprecated -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I urge you to read the OutsideIn(X) paper. I think that what you want in comment:21 is already fully implemented. You would declare `MVector` like this: {{{ data MVector m a where MVector :: PrimMonad m => !Int -> !Int -> !(MutableArray (PrimState m) a) -> MVector m a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 08:56:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 08:56:42 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.596dd19a00be27c4af783c5c1833e346@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, that's right. Looks much nicer to me. The syntax tree is ''already'' heavily decorated with `SrcSpans`. Just parameterise over that, and you can decorate with something else instead. An alternative would be to insist that there was ''always'' a `SrcSpan`, plus perhaps something else: {{{ data GenLocated l e = L SrcSpan l e type Located e = GenLocated () e }}} That's tiresome because there are lots of `()` values, but does mean you can always find a `SrcSpan`. One would have to explore use cases. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 09:04:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 09:04:02 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.8a78303d3c1fc0f5f2203e2b80540a52@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by alanz): I was considering requiring the annotation to be an instance of a class that always returned a `SrcSpan`, basically move {{{ getLoc :: GenLocated l e -> l }}} into {{{ call SrcAnnotation l where getLoc :: GenLocated l e -> SrcSpan }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 10:15:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 10:15:51 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.2ae466837498ac94d4e54de23345ae9f@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"165072b334ebb2ccbef38a963ac4d126f1e08c96/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="165072b334ebb2ccbef38a963ac4d126f1e08c96" Adapt nofib submodule to #9586 changes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 10:16:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 10:16:49 -0000 Subject: [GHC] #8369: Small improvements to ./sync-all In-Reply-To: <042.c6240151f5790c94f3ab310253d6a72c@haskell.org> References: <042.c6240151f5790c94f3ab310253d6a72c@haskell.org> Message-ID: <057.108a3d98b7256d076607f97e4357bb36@haskell.org> #8369: Small improvements to ./sync-all -------------------------------------+------------------------------------- Reporter: nwf | Owner: hvr Type: bug | Status: closed Priority: lowest | Milestone: Component: Trac & Git | Version: 7.7 Resolution: fixed | Keywords: sync-all Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: '''Note''': since all [wiki:Repositories repositories] have been turned into git submodules, you normally don't need `sync-all` anymore. See [WorkingConventions/Git git working conventions] and [WorkingConventions/Git/Submodules git submodules] for the new submodule workflow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 10:18:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 10:18:10 -0000 Subject: [GHC] #8983: sync-all get should respect branches In-Reply-To: <045.2387548a5134286050979bbad60135c3@haskell.org> References: <045.2387548a5134286050979bbad60135c3@haskell.org> Message-ID: <060.8e7fa54ffe8f46d777001d66514f78d1@haskell.org> #8983: sync-all get should respect branches -------------------------------------+------------------------------------- Reporter: ezyang | Owner: hvr Type: bug | Status: closed Priority: low | Milestone: Component: Trac & Git | Version: 7.9 Resolution: wontfix | Keywords: sync-all Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: '''Note''': since all [wiki:Repositories repositories] have been turned into git submodules, you normally don't need `sync-all` anymore. See [WorkingConventions/Git git working conventions] and [WorkingConventions/Git/Submodules git submodules] for the new submodule workflow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 10:28:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 10:28:26 -0000 Subject: [GHC] #7673: Windows: run "git config --global core.autocrlf false" before cloning the repo In-Reply-To: <047.12821fb51193c8ec9bb34376058ac256@haskell.org> References: <047.12821fb51193c8ec9bb34376058ac256@haskell.org> Message-ID: <062.2a018964d69cf11c9aa086459108a048@haskell.org> #7673: Windows: run "git config --global core.autocrlf false" before cloning the repo -------------------------------------+------------------------------------ Reporter: morabbin | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Trac & Git | Version: Resolution: wontfix | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: '''Note''': since all [wiki:Repositories repositories] have been turned into git submodules, you normally don't need `sync-all` anymore. See [WorkingConventions/Git git working conventions] and [WorkingConventions/Git/Submodules git submodules] for the new submodule workflow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 10:40:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 10:40:12 -0000 Subject: [GHC] #8251: Validate submodule references during pre-receive hook In-Reply-To: <042.3dddefcb4f2f56279562cd3ed6b1a071@haskell.org> References: <042.3dddefcb4f2f56279562cd3ed6b1a071@haskell.org> Message-ID: <057.1646e1436f5df2ae59b7947cb06e1cfa@haskell.org> #8251: Validate submodule references during pre-receive hook -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Resolution: fixed | Keywords: admin git Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8545 #8544 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Please reopen if needed: > Moreover, when adding a new submodule ref to a repository hosted at `git.haskell.org` another hook script could add a hidden ref or a [https://www.kernel.org/pub/software/scm/git/docs/git-notes.html Git note] to the referenced commit, effectively providing a back-ref, and ensuring the commit doesn't become dangling and subsequently garbage collected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 10:45:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 10:45:04 -0000 Subject: [GHC] #9366: Trac stylesheet minor cosmetic issue In-Reply-To: <046.97b3c1ae2e68483e115bd1524b22e133@haskell.org> References: <046.97b3c1ae2e68483e115bd1524b22e133@haskell.org> Message-ID: <061.ef083f872b8d21fd6f769ea001a645eb@haskell.org> #9366: Trac stylesheet minor cosmetic issue -------------------------------------+------------------------------------- Reporter: cheater | Owner: hvr Type: bug | Status: closed Priority: lowest | Milestone: Component: Trac & Git | Version: 7.8.2 Resolution: worksforme | Keywords: css, stylesheet, Operating System: | navbar Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Easy (less than 1 Test Case: | hour) Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Please file with http://trac.edgewall.org/ if you're still having problems, I think we're using the default stylesheet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 10:47:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 10:47:37 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.642ab64f2835010227d974e2918961fd@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:24 dreixel]: > If there is no opposition, I'm happy to have a go at implementing this. I agree with [comment:11 dterei] that Haddock and GHCi support would be desirable too. As I'd be excited to see this feature rather sooner than later... do you have given it a shot yet? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 10:49:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 10:49:18 -0000 Subject: [GHC] #8881: No way to unsubscribe a bug In-Reply-To: <046.3e20bef03cc312ed086d6bf0a5bf092e@haskell.org> References: <046.3e20bef03cc312ed086d6bf0a5bf092e@haskell.org> Message-ID: <061.fe2f24b6196610f4bab7a2f779b22f53@haskell.org> #8881: No way to unsubscribe a bug -------------------------------------+------------------------------------- Reporter: nomeata | Owner: hvr Type: feature | Status: closed request | Milestone: Priority: normal | Version: Component: Trac & Git | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9138 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: This is a know issue in Trac. See http://trac.edgewall.org/ticket/9971, and all tickets linked from there. Nothing we can do about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 10:55:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 10:55:07 -0000 Subject: [GHC] #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) In-Reply-To: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> References: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> Message-ID: <057.c02f25e2d01af07e29a74447de5425ca@haskell.org> #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: testcase Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Test LGTM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 12:07:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 12:07:15 -0000 Subject: [GHC] #8480: ghc 7.6.3 + clang-compatibility patches In-Reply-To: <052.478dfdb0b5fabbeb361804f90f4df852@haskell.org> References: <052.478dfdb0b5fabbeb361804f90f4df852@haskell.org> Message-ID: <067.94d8e03be9e62c7c2aa585553921606c@haskell.org> #8480: ghc 7.6.3 + clang-compatibility patches -------------------------------------+------------------------------------- Reporter: | Owner: darinmorrison | Status: closed Type: task | Milestone: Priority: high | Version: 7.6.3 Component: Compiler | Keywords: clang Resolution: wontfix | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: I'm sorry, but there won't be a 7.6.4 release. See the [wiki:Status status page] for the current release plans. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 12:07:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 12:07:33 -0000 Subject: [GHC] #8026: DatatypeContexts should be fixed, not deprecated In-Reply-To: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> References: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> Message-ID: <059.68a8bae4e0b9ef61817455a64324f8a9@haskell.org> #8026: DatatypeContexts should be fixed, not deprecated -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => wontfix Comment: I'm afraid the recent salvo of examples has done little to convince me of what this extension really means. The only I can glean from this is you want a very syntactic translation of a type `... HasEq a ...` to `Eq a => ... HasEq a ...`. The problem is that this translation doesn't always make sense, given the other features of Haskell's type system, and would either work or not work in various scenarios unpredictably. At the risk of repeating myself: those of us with experience working inside GHC and who do know type theory think this proposal doesn't fly. We love contributions and ideas from folks without this experience. But, in this case, where we disagree with the proposal, the burden rests on the proposers to convince us that the proposal holds water. The way to do this starts with a wiki page and typing rules, not just examples. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 12:20:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 12:20:46 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.cb97cc701d4e960d000161536965e31f@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Any `memcpy` of a string will not be a statically known size. Furthermore, for small strings I think the space we save by not aligning them outweighs any benefit from aligned memcpy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 12:22:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 12:22:19 -0000 Subject: [GHC] #7339: GHC fails to build from source on Alpha In-Reply-To: <045.f95316de001dc8f350b3d2e47fc53e59@haskell.org> References: <045.f95316de001dc8f350b3d2e47fc53e59@haskell.org> Message-ID: <060.be9289faced4a9775050cd7766a38b60@haskell.org> #7339: GHC fails to build from source on Alpha ----------------------------------------------+--------------------------- Reporter: creemj | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: alpha Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #617 Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by thomie): * related: => #617 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 12:22:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 12:22:30 -0000 Subject: [GHC] #617: Alpha port In-Reply-To: <047.5709ea3d43fc085734d382aa8a666d07@haskell.org> References: <047.5709ea3d43fc085734d382aa8a666d07@haskell.org> Message-ID: <062.4c9ea9f616aa7cf77202a7b04985ac5a@haskell.org> #617: Alpha port -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: None Resolution: fixed | Keywords: Operating System: | Architecture: alpha Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: | days) None/Unknown | Blocked By: Test Case: N/A | Related Tickets: #7339 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: => None/Unknown * resolution: None => fixed * related: => #7339 Comment: GHC on `alpha` seems to have been working at least as recent as November 2012, see #7339. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 12:26:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 12:26:34 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.1dd48352439755497a8bc61d0daef21e@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): Replying to [comment:27 hvr]: > As I'd be excited to see this feature rather sooner than later... do you have given it a shot yet? :) No, but maybe I can do it (or convince someone else to do it) this weekend at HacBerlin! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 12:29:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 12:29:14 -0000 Subject: [GHC] #8026: DatatypeContexts should be fixed, not deprecated In-Reply-To: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> References: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> Message-ID: <059.10a36188c83e2331073ec7d6ef5b34e0@haskell.org> #8026: DatatypeContexts should be fixed, not deprecated -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by yokto): Ok @simonpj, that's right. I think I was mistaken and this is not as important as I thought. I think I'm content with the GADT solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 12:30:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 12:30:58 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.a14a76e46ac47b2ba9f8d03c45c2da01@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): Replying to [comment:8 simonmar]: > Any `memcpy` of a string will not be a statically known size. Furthermore, for small strings I think the space we save by not aligning them outweighs any benefit from aligned memcpy. Why not? With OverloadedLists we now desugar list literals (which are really no different than string literals, conceptually) to `fromListN`, so code that creates e.g. a `ByteString` from a list literal can be implemented with a memcpy that has its argument statically known. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 12:50:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 12:50:52 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.63e37e3cb97fbe74827eb056fafab491@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by xnyhps): I found #5218, which sounds like a nice solution for bytestrings because it gives the option to do different things with string and bytestring literals (part 2 of [https://ghc.haskell.org/trac/ghc/ticket/5218#comment:3 comment 3]). I can look at this at the same time. Alternatively, using the same heuristic as GCC would also be an option: align only ?32 byte strings. (`genCCall` has a maximum length it will unroll, but I can't tell what that practically is on x86.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 12:52:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 12:52:59 -0000 Subject: [GHC] #3379: GHC should use the standard binary package In-Reply-To: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> References: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> Message-ID: <059.b3c096293be8c8e17f108ac5d791bc86@haskell.org> #3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): GHC still has is its own Binary module, see [[GhcFile(compiler/utils/Binary.hs)]] and: {{{ $ git grep 'import Binary' compiler/ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 13:15:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 13:15:46 -0000 Subject: [GHC] #8842: Make sure msys2 builds non emulating binaries In-Reply-To: <046.86a6364bab91651953306fe81692398f@haskell.org> References: <046.86a6364bab91651953306fe81692398f@haskell.org> Message-ID: <061.a3f3bcbe313c6394b6d0d079b0d86e46@haskell.org> #8842: Make sure msys2 builds non emulating binaries -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.1-rc2 System | Keywords: msys2 Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => msys2 * component: Compiler => Build System -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 13:38:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 13:38:04 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.70597d52bff9dc7374de60796d56ee1e@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): If I have a server today that serves a large literal ByteString in response to a particular request, presumably that string buffer will get copied out of at some point?maybe even by the kernel. That memcpy probably won't have statically known size or alignment but it probably will determine at runtime that the size is large and alignment is suitable for doing a more efficient copy. Replying to [comment:10 xnyhps]: > Alternatively, using the same heuristic as GCC would also be an option: align only ?32 byte strings. (`genCCall` has a maximum length it will unroll, but I can't tell what that practically is on x86.) I think we should just do this (at least for now). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 13:45:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 13:45:12 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.94e588730ce48ec3a04f9fc7b731b671@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:4 dfeuer]: > You mention that there are a lot of string literals in the Prelude. I would bet that the vast majority of those are error messages. Might it be possible to specifically target ''exceptional'' strings that should never be anywhere speed-critical, and pack them all together? Putting them all together, ideally starting or ending on a page boundary, would (hopefully) mean that they wouldn't even need to be swapped in unless an error occurred. I think this is easy to do as far as the linker side of things is concerned (just put the exceptional strings in their own section); the only bit that might be tricky is identifying which string literals should be considered exceptional and plumbing that information through the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 14:09:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 14:09:07 -0000 Subject: [GHC] #5556: Support pin-changing on ByteArray#s In-Reply-To: <046.1b81478cf84dfba9336774f0fe7553f1@haskell.org> References: <046.1b81478cf84dfba9336774f0fe7553f1@haskell.org> Message-ID: <061.e9271dcdea5d13c5352c6b7a188e2e44@haskell.org> #5556: Support pin-changing on ByteArray#s -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Let me make sure I've got this right: pinned ByteArrays currently live on a totally different heap than unpinned ones, right? If you pin an unpinned ByteArray without copying it, now you have a hole in the middle of your GC area to allocate around. I suppose you could split the containing GC block into two? a reasonable thing to do if you don't expect many temporarily- pinned ByteArrays to exist at any given time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 14:19:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 14:19:16 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.1d15d31eedab7c6ad8fb8eac259c1a9a@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Can't we determine the context for the derived instance from the contexts of the default method type signatures? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 14:38:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 14:38:29 -0000 Subject: [GHC] #3355: Refactor Template Haskell syntax conversions In-Reply-To: <047.1f46b8c5776cfa915775f27bfb2f30b5@haskell.org> References: <047.1f46b8c5776cfa915775f27bfb2f30b5@haskell.org> Message-ID: <062.7fbf39bb4d4ed8ee9527edb828a9c500@haskell.org> #3355: Refactor Template Haskell syntax conversions -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.10.1 Component: Template | Version: 6.10.3 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => None/Unknown * component: Compiler => Template Haskell Old description: > On [wiki:Commentary/Compiler/TemplateHaskell] there is a proposed > refactoring of the Tempate Haskell-related syntax conversions. This task > is to do that refactoring. New description: On [wiki:TemplateHaskell/Conversions] there is a proposed refactoring of the Tempate Haskell-related syntax conversions. This task is to do that refactoring. Edit: link. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 14:53:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 14:53:38 -0000 Subject: [GHC] #8782: Using GADT's to maintain invariant in GHC libraries In-Reply-To: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> References: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> Message-ID: <066.e13be81a27db6ac6401983c107663136@haskell.org> #8782: Using GADT's to maintain invariant in GHC libraries -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: patch Type: task | Milestone: 7.10.1 Priority: lowest | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:00:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:00:17 -0000 Subject: [GHC] #9248: Document -XHaskell98 and -XHaskell2010 in flag reference In-Reply-To: <047.f98b7df1c3966676c7fecca73ea7b44a@haskell.org> References: <047.f98b7df1c3966676c7fecca73ea7b44a@haskell.org> Message-ID: <062.df5226908dc5f7e5fa81ba0ab8230222@haskell.org> #9248: Document -XHaskell98 and -XHaskell2010 in flag reference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.9 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1880 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * version: 7.8.2 => 7.9 * related: => #1880 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:00:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:00:39 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.ec8ece244fe14fc6333d2727f8664e59@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: #1880 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #1880 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:01:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:01:03 -0000 Subject: [GHC] #9247: Document -XDatatypeContexts in flag reference In-Reply-To: <047.5847e6375288b1fe9155bf048d9f1ac4@haskell.org> References: <047.5847e6375288b1fe9155bf048d9f1ac4@haskell.org> Message-ID: <062.a84403fc0a7ad015bc6efe0760fc5379@haskell.org> #9247: Document -XDatatypeContexts in flag reference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: | Version: 7.9 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1880 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * version: 7.8.2 => 7.9 * related: => #1880 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:08:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:08:03 -0000 Subject: [GHC] #3646: Enforce requirement that our repos contains a subset of upstream's patches In-Reply-To: <044.3251c5b214325160caef2f0092388f6b@haskell.org> References: <044.3251c5b214325160caef2f0092388f6b@haskell.org> Message-ID: <059.855c7f91967bee8cef3de36c54d0c5d0@haskell.org> #3646: Enforce requirement that our repos contains a subset of upstream's patches -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: closed Priority: lowest | Milestone: Component: Trac & Git | Version: Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8251 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * component: Compiler => Trac & Git * related: => #8251 * failure: => None/Unknown * version: 6.10.4 => * milestone: 7.10.1 => * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:13:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:13:26 -0000 Subject: [GHC] #888: Implement the static argument transformation In-Reply-To: <046.4f72376cf2bb17c84e2a65a1a9e8119c@haskell.org> References: <046.4f72376cf2bb17c84e2a65a1a9e8119c@haskell.org> Message-ID: <061.e69149e14f4fb7e9fa21aaf3509d9034@haskell.org> #888: Implement the static argument transformation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): I?m confused. There is `-fstatic-argument-transformation`. Shouldn?t this be closed? There is also #9374 about the need to make SAT better... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:20:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:20:51 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) Message-ID: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time performance bug Related Tickets: #9583 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is a continuation of #9583 Compiling latest Cabal from Git's `Language.Haskell.Extension` module shows a significant performance regression with respect to GHC 7.8.3: {{{ $ uname -a Linux duo 3.17.0-031700rc6-generic #201409211935 SMP Sun Sep 21 23:37:11 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ git describe cabal-install_merged-1912-g7161e4c ######################################################################################## $ /opt/ghc/7.8.3/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 $ /opt/ghc/7.8.3/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs <> ######################################################################################## $ /opt/ghc/head/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.9.20140923 $ /opt/ghc/head/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs <> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:22:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:22:44 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.9bd66110a166bc3f4b1988fc4594fc1c@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: #9630 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * related: => #9630 Comment: I've created a new ticket for the performance regression over at #9630 to separate concerns a bit -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:26:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:26:20 -0000 Subject: [GHC] #9535: Remove max_bytes_used from haddock tests In-Reply-To: <046.b450aff06541c96c843901eaaf37ab41@haskell.org> References: <046.b450aff06541c96c843901eaaf37ab41@haskell.org> Message-ID: <061.fc4407807866961dbcdc57b8c82516ba@haskell.org> #9535: Remove max_bytes_used from haddock tests -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * version: 7.8.2 => 7.9 * resolution: => fixed * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:34:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:34:48 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.cbd543b3a040f4d6acf03297ce91eb12@haskell.org> #3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: kseo Type: task | Status: new Priority: normal | Milestone: ? Component: Test Suite | Version: Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * version: 6.10.4 => Comment: kseo: did you manage to get something going? Please ask questions on irc if you have any, maybe somebody can help you out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:38:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:38:53 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.37aadcbb6191366eb3109b2a2ada9a26@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by xnyhps): Documenting what I found about merging duplicate string constants in GCC/clang: Turning on `-fmerge-constants` with GCC changes the generated assembly: {{{ - .section .rodata + .section .rodata.str1.1,"aMS", at progbits,1 }}} As far as I can tell, this stands for: * `a` sets `SHF_ALLOC` * `M` sets `SHF_MERGE` * `S` sets `SHF_STRINGS` * `@progbits` sets `SHT_PROGBITS` * The `1` indicates the size of each entry (character) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:39:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:39:08 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.bac6cbe54fcbfd6292394d5ce60c7a81@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9583 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Old description: > This is a continuation of #9583 > > Compiling latest Cabal from Git's `Language.Haskell.Extension` module > shows a significant performance regression with respect to GHC 7.8.3: > > {{{ > $ uname -a > Linux duo 3.17.0-031700rc6-generic #201409211935 SMP Sun Sep 21 23:37:11 > UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > $ git describe > cabal-install_merged-1912-g7161e4c > > ######################################################################################## > > $ /opt/ghc/7.8.3/bin/ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.8.3 > > $ /opt/ghc/7.8.3/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs > < residency (14 samples), 273M in use, 0.00 INIT (0.03 elapsed), 4.96 MUT > (5.28 elapsed), 3.26 GC (3.47 elapsed) :ghc>> > > ######################################################################################## > > $ /opt/ghc/head/bin/ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.9.20140923 > > $ /opt/ghc/head/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs > < residency (30 samples), 2096M in use, 0.001 INIT (0.001 elapsed), 133.003 > MUT (142.730 elapsed), 73.241 GC (78.234 elapsed) :ghc>> > }}} New description: This is a continuation of #9583 Compiling latest Cabal from Git's `Language.Haskell.Extension` module shows a significant performance regression with respect to GHC 7.8.3: {{{ $ uname -a Linux duo 3.17.0-031700rc6-generic #201409211935 SMP Sun Sep 21 23:37:11 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ git describe cabal-install_merged-1912-g7161e4c ############################################################################# $ /opt/ghc/7.8.3/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 $ /opt/ghc/7.8.3/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs <> ############################################################################# $ /opt/ghc/head/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.9.20140923 $ /opt/ghc/head/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs <> }}} Or in other words, this represents a ~7.7x "memory in use" and ~26x elapsed time regression -- Comment (by hvr): description line-wrapped for readability -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:45:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:45:20 -0000 Subject: [GHC] #8290: lookupSymbol API is unsafe In-Reply-To: <045.df7ffdb732cb71d0a322e1094e9d2a99@haskell.org> References: <045.df7ffdb732cb71d0a322e1094e9d2a99@haskell.org> Message-ID: <060.f6e5d88c9bc3895c52c4eabbe86c7787@haskell.org> #8290: lookupSymbol API is unsafe -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * version: 7.7 => 7.9 Old description: > lookupSymbol is one of those functions that looks nice and innocuous on > the tin, until you realize actually it doesn't actually do what you want, > and seduces you into writing code that doesn't work on Mac OS X. Case in > point, this recent test suite commit: > > {{{ > commit 29b0521cd9be39b4026103d184d1fec14ef3bc22 > Author: Edward Z. Yang > Date: Fri Sep 13 20:52:57 2013 -0700 > > Properly provide leading underscore when necessary. > > Signed-off-by: Edward Z. Yang > }}} > > Yes, the API is "correct" in some sense, but from a portability sense, we > really want the function to add the underscore itself. > > If we change this particular function, we will probably break most > dynamic loading code (including GHC's). We could also add a safe variant > of the function. We just need to decide something to do. New description: lookupSymbol is one of those functions that looks nice and innocuous on the tin, until you realize actually it doesn't actually do what you want, and seduces you into writing code that doesn't work on Mac OS X. Case in point, this recent test suite commit: {{{ commit 02d4958903e967b78fc3bbceddc2ce8ce33901c0 Author: Edward Z. Yang Date: Fri Sep 13 20:52:57 2013 -0700 Properly provide leading underscore when necessary. Signed-off-by: Edward Z. Yang }}} Yes, the API is "correct" in some sense, but from a portability sense, we really want the function to add the underscore itself. If we change this particular function, we will probably break most dynamic loading code (including GHC's). We could also add a safe variant of the function. We just need to decide something to do. -- Comment: Link to mentioned commit: 02d4958903e967b78fc3bbceddc2ce8ce33901c0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:53:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:53:52 -0000 Subject: [GHC] #888: Implement the static argument transformation In-Reply-To: <046.4f72376cf2bb17c84e2a65a1a9e8119c@haskell.org> References: <046.4f72376cf2bb17c84e2a65a1a9e8119c@haskell.org> Message-ID: <061.289270dbd43d09a141b5464800305728@haskell.org> #888: Implement the static argument transformation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by choenerzs): I think this issue tracks work on SAT for stream fusion / concatMap. Probably the more generic case as well, but I think I added myself to CC because of stream fusions concatMap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:57:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:57:40 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.44d052d6a64bfc528b4fb7804b40f1cd@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9583 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): What makes you think it's due to Generics? Not much changed there since 7.8... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 15:58:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 15:58:43 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.d200b93df57984ee8bd07958f8222eef@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9583 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): Oh, I didn't notice that I was CC-ed on that other ticket. I will have a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 16:04:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 16:04:40 -0000 Subject: [GHC] #5794: Nofib nightly regressions with pretty graphs In-Reply-To: <045.be760f7d14e922c2847d801465589282@haskell.org> References: <045.be760f7d14e922c2847d801465589282@haskell.org> Message-ID: <060.7297f19ae5a53b371fadbb2930b9b216@haskell.org> #5794: Nofib nightly regressions with pretty graphs -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: closed Priority: normal | Milestone: ? Component: NoFib | Version: benchmark suite | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * blockedby: 5793 => Comment: See http://ghcspeed-nomeata.rhcloud.com/, linked to from the [wiki:Infrastructure] page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 16:11:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 16:11:07 -0000 Subject: [GHC] #8992: Instructions for using gdb with GHC on Windows In-Reply-To: <045.5da142d588020e3fc1397add8a636ef7@haskell.org> References: <045.5da142d588020e3fc1397add8a636ef7@haskell.org> Message-ID: <060.37ebaa1a969948a3089a7efc807b7cec@haskell.org> #8992: Instructions for using gdb with GHC on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: Documentation | Keywords: msys,msys2 Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => msys,msys2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 16:20:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 16:20:43 -0000 Subject: [GHC] #9338: Some ghc options do not seem to be documented: In-Reply-To: <042.e12c509cb214268f1f7773d34219ca1f@haskell.org> References: <042.e12c509cb214268f1f7773d34219ca1f@haskell.org> Message-ID: <057.82e08a2c8fa81ca61c0cc7a68d0892da@haskell.org> #9338: Some ghc options do not seem to be documented: -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9358, #1880 Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #9358, #1880 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 17:01:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 17:01:17 -0000 Subject: [GHC] #8529: Sequent reading from socket/connection on Windows fails In-Reply-To: <047.0bcc31cddfb5771ca556c838f2877e1c@haskell.org> References: <047.0bcc31cddfb5771ca556c838f2877e1c@haskell.org> Message-ID: <062.4136e563a0344d63d9106ecc2ed9ed71@haskell.org> #8529: Sequent reading from socket/connection on Windows fails -------------------------------------+------------------------------------- Reporter: Heimdell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 7.4.2 Resolution: invalid | Keywords: sockets, windows, Operating System: Windows | read failure Type of failure: Incorrect | Architecture: Unknown/Multiple result at runtime | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid * component: libraries/haskell2010 => None Comment: Thank you for the report. This is however not a bug in GHC or one of the [https://www.haskell.org/ghc/docs/latest/html/libraries/index.html libraries] supplied with GHC. It is rather a problem in your code or in in one of the network libraries you are using. Please try asking on stackoverflow first, attaching you full program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 19:00:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 19:00:34 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.de9e002e20a2664defce116aab0bc207@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:12 rwbarton]: > I think this is easy to do as far as the linker side of things is concerned (just put the exceptional strings in their own section); the only bit that might be tricky is identifying which string literals should be considered exceptional and plumbing that information through the compiler. I think identifying them shouldn't be too hard (in enough cases to be useful)?they're not exported and they appear only as arguments to `error` or possibly other exception-raising functions. I say possibly because I imagine there may be situations where exceptions that carry strings may need to be handled quickly. I imagine, however, that in those cases the strings themselves may not be inspected. Another thought is that there's probably an open source or public domain block compression algorithm that can fit in a few hundred bytes of slow assembly to access a compressed error string region. Such a thing should of course be optional if we decide to do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 19:20:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 19:20:14 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.0988d649e9523d32c3534e7ea6b178c8@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): One question I've got about this whole thread is this: What would this improve? I'm trying to understand how this will impact application performance or binary sizes (though i understand the latter is defnitely neglible) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 21:12:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 21:12:56 -0000 Subject: [GHC] #888: Implement the static argument transformation In-Reply-To: <046.4f72376cf2bb17c84e2a65a1a9e8119c@haskell.org> References: <046.4f72376cf2bb17c84e2a65a1a9e8119c@haskell.org> Message-ID: <061.d33d7182872630ce85bcbc3a52b2cc4e@haskell.org> #888: Implement the static argument transformation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): The current SAT pass has received no love for many years. Its heuristics have not been explored systematically. I opened this ticket to record a set of heuristics that might work better. But I don't think anyone has followed it up. Probably this could be combined with #9374 though. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 21:24:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 21:24:21 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.7d1ffe1b671d22256ace04d0eda29d66@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:15 carter]: > One question I've got about this whole thread is this: > What would this improve? I'm trying to understand how this will impact application performance or binary sizes (though I understand the latter is definitely neglible) Very good question. As someone who knows very little about these issues, it seems to me that there are probably approximately three related issues that will affect performance: 1. Aligning strings to word boundaries seems to be good for all sorts of reasons (comparison, copying, searching, etc.). 2. Arranging for code that (exclusively) uses a string to be likely to bring the beginning of the string in on its cache line should often be good. This kind of thing goes beyond strings, of course, and I have no idea what GHC does about it in general. 3. Dragging an error message fragment in on a cache line should always be bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 24 21:28:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Sep 2014 21:28:23 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.0bc22c8b7172e311ea5d9b5ea20c245b@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): these are great hypotheses, but the question is "do they make a measurable difference on any code perf?" Are there ways we can measure this without having to do the whole change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 01:38:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 01:38:40 -0000 Subject: [GHC] #9607: Programs that require AllowAmbiguousTypes in 7.8 (was: Type checking regression between GHC 7.6 and 7.8) In-Reply-To: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> References: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> Message-ID: <063.368b30ba063ce7093d18469be00c319c@haskell.org> #9607: Programs that require AllowAmbiguousTypes in 7.8 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 06:31:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 06:31:15 -0000 Subject: [GHC] #9631: Comment in GHC.Base about GHC.Prim does not appear to be correct Message-ID: <045.cbd722b3600402ea72fb22a56a8d8e08@haskell.org> #9631: Comment in GHC.Base about GHC.Prim does not appear to be correct -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The comment reads {{{ GHC.Prim Has no implementation. It defines built-in things, and by importing it you bring them into scope. The source file is GHC.Prim.hi-boot, which is just copied to make GHC.Prim.hi }}} It does not appear that any files by these names exist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 07:37:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 07:37:15 -0000 Subject: [GHC] #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build In-Reply-To: <045.67b198827318e5a03441f1825701405b@haskell.org> References: <045.67b198827318e5a03441f1825701405b@haskell.org> Message-ID: <060.ea69ccb5156ab5b7e200b26c8a044df5@haskell.org> #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:7 quantheory]: > I did find the issues with scanl and reverse; in fact, even after fixing `reverse . scanl f z $ xs`, I still had issues with `reverse . scanl f z . reverse $ xs`. But I did eventually fix both cases with this change: > > https://github.com/quantheory/ww- fusion/commit/74618328c34572270154dbd93eb441f448760e0e I must admit I'm still nervous about that implementation, for the very simple and unscientific reason that your unwrapper has a `_` in it: {{{#!hs (\u -> Env $ \k b -> unwrap $ \e _ -> u e k b) }}} The fact that it makes me nervous does not mean that it's actually wrong, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 07:38:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 07:38:48 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.30d546ebb92f998aa4852438eb83996f@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): > Are there ways we can measure this without having to do the whole change? Was there ever any optimisation which impact we could measure without implementing it? (I'm asking seriously.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 08:50:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 08:50:13 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.144bc7bf31a6a4d0a4f203d486ce7996@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by alanz): Once the parameter is added to the hsSyn structures, there are two ways to work it forward. 1. Work it in as a parameter throughout all the compiler passes 2. Hard code it to SrcSpan for renamer onwards Option 1 allows tool writers to add annotations and then submit for further processing, but sprinkles the parameter variable throughout the code base. Option 2 provided the most value for tool developers. Which road? I am leaning towards working it all the way through. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 08:54:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 08:54:30 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.10a988ec565132db8f7af64db3500877@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by xnyhps): Replying to [comment:15 carter]: > One question I've got about this whole thread is this: > What would this improve? I'm trying to understand how this will impact application performance or binary sizes (though i understand the latter is defnitely neglible) I think the performance loss for `[Char]`-strings is negligible: sharing means they are going to be unpacked just once, that's not worthy optimizing performance for. After unpacking the literal is never used again. `ByteString`s may have noticeable impact. Prepending a `ByteString` literal onto another `ByteString` involves a `memcpy` of the literal string. There might be code out there that does it millions of times. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 12:15:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 12:15:52 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.c58fa92d2d94375e52f81604edd5d5e5@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 12:25:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 12:25:06 -0000 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> Message-ID: <066.6cbc3a69d804c381b318e6a159118a15@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac | Owner: Dupree | Status: new Type: feature | Milestone: ? request | Version: 6.10.2 Priority: normal | Keywords: backpack Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by asr): * cc: andres.sicard.ramirez@? (removed) * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 12:29:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 12:29:07 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.7bba8d7c6319835fb5e9e37f3d5e6faf@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): I've emailed the developers whose name show up in Phab:P22 suggesting to remove tabs in the modules they had touched last according to Git. Hopefully, the Haskell modules in `ghc.git` will be tab-free soon... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 12:32:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 12:32:57 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.0ad1f760efd1986f67b259ad8fa359bd@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: monoidal Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D233 | -------------------------------------+------------------------------------- Comment (by aspidites): Ugh. Got backlogged with school. I'm reading the phabricator documentation right now though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 12:36:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 12:36:16 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.701ffdc6d551a6e5e5174ecb2485e114@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: monoidal Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D233 | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:12 aspidites]: > Ugh. Got backlogged with school. I'm reading the phabricator documentation right now though. TLDR: Just head over to Phab:D233 and look through the code. You can comment inline, and don't forget to submit all inline-comments (otherwise they don't become visible for others) when you're done with the form at the very end of that page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 12:39:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 12:39:35 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.8fed9235301eba65217e3412f8a4e85c@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9583 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * priority: normal => high Comment: increasing priority, as Phab:D183 has landed and therefore is starting to affect buildbots and developers working on GHC HEAD -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 13:04:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 13:04:17 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs In-Reply-To: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> References: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> Message-ID: <066.2ac5ff4a8320f288201f1a5ea5469046@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: patch Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: InstanceSigs (Type checker) | TypeFamilies Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by andreas.abel): Thanks for the help! Now I use PatSigOrigin to swap expected/actual type in the error message generated by tcSubType. {{{#!hs -- Check that type provided in the type signature -- is both a sub- and a super-type of the type -- originating from the method signature in the class. -- As a consequence, the types are equal, and we can discard -- the coercions. (Keep fingers crossed.) let ctOrigin = AmbigOrigin userTypeCtxt void $ tcSubType ctOrigin userTypeCtxt sig_ty local_meth_ty -- In case the provided type is more general than the expected -- type, we take care that the error reports actual and -- expected type correctly. -- Using PatSigOrigin does the job, but it is a bit hacky. void $ tcSubType PatSigOrigin userTypeCtxt local_meth_ty sig_ty }}} This does the job, however, is a bit hacky. I tried a more principled solution with TypeEqOrigin, {{{#!hs let ctOrigin' = TypeEqOrigin { uo_actual = sig_ty , uo_expected = local_meth_ty } void $ tcSubType ctOrigin' userTypeCtxt local_meth_ty sig_ty }}} but except for PatSigOrigin, instances of CtOrigin are ignore in tcSubType, or rather, converted to a standard TypeEqOrigin (with expected/actual ordered not in the way I want to). See TcUnify.lhs: {{{#!hs tcSubType :: CtOrigin -> UserTypeCtxt -> TcSigmaType -> TcSigmaType -> TcM HsWrapper -- Check that ty_actual is more polymorphic than ty_expected -- Both arguments might be polytypes, so we must instantiate and skolemise -- Returns a wrapper of shape ty_actual ~ ty_expected tcSubType origin ctxt ty_actual ty_expected ... unify ty_actual ty_expected ... where -- In the case of patterns we call tcSubType with (expected, actual) -- rather than (actual, expected). To get error messages the -- right way round we have to fiddle with the origin unify ty1 ty2 = uType u_origin ty1 ty2 where u_origin = case origin of PatSigOrigin -> TypeEqOrigin { uo_actual = ty2, uo_expected = ty1 } _other -> TypeEqOrigin { uo_actual = ty1, uo_expected = ty2 } }}} This could be changed of course, bit there is a principal risk of breaking something. In particular, would it not make sense to preserve TypeEqOrigin? {{{#!hs TypeEqOrigin{} -> u_origin }}} If you give your OK, I implement this to make my fix of #9582 cleaner. Working fix on https://github.com/andreasabel/ghc/commit/29a2f93a26f714b79a59617d20b73b2e166cc62c some cleaning needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 13:29:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 13:29:11 -0000 Subject: [GHC] #9632: Promotable type synonyms (or: synonyms to promoted types) Message-ID: <048.8fe52c5c00b593ea5a85c15f59bf61ed@haskell.org> #9632: Promotable type synonyms (or: synonyms to promoted types) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I want to use '''synonyms to promoted types''' in the same places where I can use the '''promoted types''': {{{#!hs {-# LANGUAGE DataKinds, KindSignatures #-} module PromotableTypeSynonyms where data B = T | F data P :: B -> * type B' = B data P' :: B' -> * -- using B' synonym here is currently not allowed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 14:07:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 14:07:27 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.4fb6af8fc99de591845a0ddf8ed5182f@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9583 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm happy to support, but I currently believe that this isn't a GHC shortcoming. I'm willing to revise that view if evidence emerges! A good starting point might be the amount of code generated by Edward's example in comment 5 of #9583 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 14:11:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 14:11:58 -0000 Subject: [GHC] #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> In-Reply-To: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> References: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> Message-ID: <062.567d99ea6026c518d8d5e680db149dbc@haskell.org> #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): This might also be the cause of https://github.com/kolmodin/binary/issues/60. Could we have a 7.8.4 release? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 14:15:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 14:15:47 -0000 Subject: [GHC] #9632: Promotable type synonyms (or: synonyms to promoted types) In-Reply-To: <048.8fe52c5c00b593ea5a85c15f59bf61ed@haskell.org> References: <048.8fe52c5c00b593ea5a85c15f59bf61ed@haskell.org> Message-ID: <063.bbabbff26550c3264b21789d17fbe766@haskell.org> #9632: Promotable type synonyms (or: synonyms to promoted types) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): This is part of the solution to #7961, which I am actively working on. But don't hold your breath -- it won't be done for a few more months, and then I have to convince folks to merge my branch with significant changes in it. If someone else wants to address just this point on a shorter timeline, go ahead! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 14:19:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 14:19:53 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.3fd0c6b4f2882d70fc3d931676c8dffc@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9583 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): I'm happy to investigate the problem, but it will take a few days, so we might need some temporary workaround. In fact, I can't even build HEAD at the moment (my VM runs out of memory), because of this. Can the Binary instances be disabled in Cabal for a while? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 14:48:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 14:48:16 -0000 Subject: [GHC] #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> In-Reply-To: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> References: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> Message-ID: <062.af97b9ef01b77320dea6914c68322362@haskell.org> #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you not just switch off `SpecConstr`? But in principle, yes, if there is user pressure, we could push out 7.8.4 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 15:23:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 15:23:00 -0000 Subject: [GHC] #9633: PolyKinds in 7.8.2 vs 7.8.3 Message-ID: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> #9633: PolyKinds in 7.8.2 vs 7.8.3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: PolyKinds | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code '''compiles''' with GHC 7.8.2. This code has been distilled down from a larger example where I needed `-XPolyKinds` in Bar.hs but not in Foo.hs. In addition, the `modify` function is supposed to modify a mutable `Data.Vector`, hence the inner `go` function has the intended type of `Int -> m ()`, though strictly speaking it could return any value since everything is discarded by the `forM_`. {{{ -- {-# LANGUAGE PolyKinds #-} module Foo where import Control.Monad (forM_) import Control.Monad.Primitive import Bar -- Vector signatures unsafeRead :: (PrimMonad m) => v (PrimState m) a -> Int -> m a unsafeRead = error "type only" unsafeWrite :: (PrimMonad m) => v (PrimState m) a -> Int -> a -> m () unsafeWrite = error "type only" modify :: Int -> Bar v r modify p = Bar (p-1) $ \y -> do let go i = do a <- unsafeRead y i unsafeWrite y i a --return a forM_ [0..(p-1)] go }}} {{{ {-# LANGUAGE RankNTypes, PolyKinds #-} module Bar where import Control.Monad.Primitive data Bar v r = Bar Int (forall s . (PrimMonad s) => v (PrimState s) r -> s ()) }}} In 7.8.3, this above code results in the error (with `-fprint-explicit- kinds`) {{{ Foo.hs:19:23: Couldn't match type ?a0? with ?r? ?a0? is untouchable inside the constraints (PrimMonad m, (~) * (PrimState m) (PrimState s)) bound by the inferred type of go :: (PrimMonad m, (~) * (PrimState m) (PrimState s)) => Int -> m () at Foo.hs:(18,7)-(20,23) ?r? is a rigid type variable bound by the type signature for modify :: Int -> Bar * v r at Foo.hs:16:11 Expected type: v0 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeRead?, namely ?y? In a stmt of a 'do' block: a <- unsafeRead y i Foo.hs:20:19: Couldn't match type ?v1? with ?v? ?v1? is untouchable inside the constraints (PrimMonad m, (~) * (PrimState m) (PrimState s)) bound by the inferred type of go :: (PrimMonad m, (~) * (PrimState m) (PrimState s)) => Int -> m () at Foo.hs:(18,7)-(20,23) ?v? is a rigid type variable bound by the type signature for modify :: Int -> Bar * v r at Foo.hs:16:11 Expected type: v1 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeWrite?, namely ?y? ... Failed, modules loaded: Bar. }}} After much digging, I found that enabling `-XPolyKinds` in Foo.hs gives a more meaningful error: {{{ Foo.hs:19:23: Could not deduce ((~) (* -> k -> *) v v0) ... Expected type: v0 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeRead?, namely ?y? In a stmt of a 'do' block: a <- unsafeRead y i Foo.hs:20:19: Could not deduce ((~) (* -> k -> *) v v1) ... Expected type: v1 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeWrite?, namely ?y? In a stmt of a 'do' block: unsafeWrite y i a Failed, modules loaded: Bar. }}} Adding `PolyKinds` to Foo.hs ''and'' uncommenting `return a` results in the error: {{{ Foo.hs:17:12: Couldn't match kind ?k? with ?k1? because type variable ?k1? would escape its scope This (rigid, skolem) type variable is bound by the type signature for modify :: Int -> Bar k1 v r at Foo.hs:16:11-24 Expected type: Bar k1 v r Actual type: Bar k v0 r0 ... In the expression: Bar (p - 1) $ \ y -> do { let ...; forM_ [0 .. (p - 1)] go } ... Foo.hs:18:7: Kind incompatibility when matching types: v0 :: * -> k -> * v1 :: * -> * -> * ... When checking that ?go? has the inferred type ?forall (k :: BOX) (m :: * -> *) b (v :: * -> * -> *) (v1 :: * -> * -> *). ((~) (* -> k -> *) v0 v, (~) k r0 b, (~) (* -> k -> *) v0 v1, PrimMonad m, (~) * (PrimState m) (PrimState s)) => Int -> m b? Probable cause: the inferred type is ambiguous In the expression: do { let go i = ...; forM_ [0 .. (p - 1)] go } ... Failed, modules loaded: Bar. }}} These errors can be resolved by modifying the original code above in any of the following ways: 1. Remove `-XPolyKinds` from Bar.hs 2. Add an explicit kind signature to the `v :: * -> * -> *` parameter of type `Bar` 3. With `PolyKinds` in Bar but *not* Foo, uncommenting `return a` make GHC 7.8.3. compile What I'm trying to understand is 1. Why there is different behavior from 7.8.2 to 7.8.3. There doesn't seem to be anything addressing `PolyKinds` in the [http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/release-7-8-3.html release notes vs 7.8.2] . 2. In the event the above code should not compile with 7.8.3, there error message could be much clearer. The first error message above didn't help me understand that `PolyKinds` was to blame, while the second error did a better job, and the third was very clearly a `PolyKinds` issue (i.e. `kind mismatch`) 3. For the third resolution option above, I can't see any reason that adding `return a` to the inner `go` function should make the code compile while leaving it out makes the code somehow ambiguous. This, if nothing else, seems like a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 16:10:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 16:10:32 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.1fc07c9094e9404a2bdc83c4c926c6e5@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8731 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Feuerbach): Is there an easy way to check what exactly takes up the time: generating the ast, renaming/typechecking it, generating the output code? Or do I have to compile ghc with profiling for that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 16:29:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 16:29:00 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.de043bed25f195347e76d5c78d626e79@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by alanz): On further reflection, option 1 will allow for example a smart editor which uses the annotated `ParsedSource` as a primary data structure and submits changes through for incremental renaming/type checking and eventual code generation. This way the normal command line invocation will lock the annotation down as a `SrcSpan`, but it can be replaced all the way through when used for tooling. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 16:53:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 16:53:10 -0000 Subject: [GHC] #9633: PolyKinds in 7.8.2 vs 7.8.3 In-Reply-To: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> References: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> Message-ID: <062.2d58bf215690f8d8feee83d763d0820e@haskell.org> #9633: PolyKinds in 7.8.2 vs 7.8.3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PolyKinds Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Where does `Control.Monad.Primitive` come from? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 16:58:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 16:58:44 -0000 Subject: [GHC] #9633: PolyKinds in 7.8.2 vs 7.8.3 In-Reply-To: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> References: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> Message-ID: <062.7bc51161ed2a63dfc8fd4b2d0482dc82@haskell.org> #9633: PolyKinds in 7.8.2 vs 7.8.3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PolyKinds Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by refold): Replying to [comment:1 simonpj]: > Where does `Control.Monad.Primitive` come from? From [http://hackage.haskell.org/package/primitive-0.5.3.0/docs/Control- Monad-Primitive.html this package]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 17:07:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 17:07:03 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.e92fe0509a6e11045924070467b75b54@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Criterion has spoken. `dropWhileEnd isSpace` seems to be much slower in typical cases than even `reverse . dropWhile isSpace . reverse`. Even a faster predicate, `(== ' ')`, gives a (much smaller) disadvantage to `dropWhileEnd`. However, the above `dropWhileEndLE` appears to be faster than the double reverse in all cases. So I'll add it to the utilities module and use that instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 17:37:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 17:37:02 -0000 Subject: [GHC] #9633: PolyKinds in 7.8.2 vs 7.8.3 In-Reply-To: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> References: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> Message-ID: <062.221bcd195fa0e11701accd39362da770@haskell.org> #9633: PolyKinds in 7.8.2 vs 7.8.3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PolyKinds Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I looked a little at this, and `Control.Monad.Primitive` isn't integral to the problem. Just replace `PrimMonad` with `Monad` and use a fresh type family for `PrimState`. Didn't figure out much beyond that, but I only tried for 5 minutes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 20:22:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 20:22:07 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.e9728f1c7766c0ec1860955b99241589@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9583 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"3ecca02516af5de803e4ff667c8c969c5bffb35f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3ecca02516af5de803e4ff667c8c969c5bffb35f" Update `binary` submodule in an attempt to address #9630 This removes a couple of `INLINE` pragmas from the generics helper classes. With this change the compile times and memory usage should go back to the previous GHC 7.8.3 situation. This has been submitted upstream as https://github.com/kolmodin/binary/pull/62 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 21:07:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 21:07:11 -0000 Subject: [GHC] #7544: GHC downloads are unsigned In-Reply-To: <046.6053a1925ff3f9f709d272bbee881ce0@haskell.org> References: <046.6053a1925ff3f9f709d272bbee881ce0@haskell.org> Message-ID: <061.596b0d10b6138120637ba292d60fa18b@haskell.org> #7544: GHC downloads are unsigned --------------------------------------------+--------------------------- Reporter: afcowie | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | --------------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Thank you for your feature request. sha256 hashes are available since version 7.8.1, and linked to from the download page. For the latest release, check [http://www.haskell.org/ghc/dist/7.8.3/SHA256SUMS here]. I hope that solves things for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 21:26:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 21:26:07 -0000 Subject: [GHC] #7544: GHC downloads are unsigned In-Reply-To: <046.6053a1925ff3f9f709d272bbee881ce0@haskell.org> References: <046.6053a1925ff3f9f709d272bbee881ce0@haskell.org> Message-ID: <061.af7463dd1340b827d35b06f2674c2c0d@haskell.org> #7544: GHC downloads are unsigned --------------------------------------------+--------------------------- Reporter: afcowie | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | --------------------------------------------+--------------------------- Comment (by nomeata): GPG signatures would still be nice. For example uscan, the tool Debian uses to download upstream tarballs, can automatically verify them by including the corresponding key in the Debian packaging meta-data. (Not reopening, though, it?s just a thing that?s nice to have, but there are more important things I guess). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 21:26:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 21:26:14 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.e3cda377ecd76e238107c391c2e10c26@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by alanz): Question: can I rip `hooks` out of `DynFlags`, to be managed separately? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 25 21:41:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Sep 2014 21:41:59 -0000 Subject: [GHC] #7544: GHC downloads are unsigned In-Reply-To: <046.6053a1925ff3f9f709d272bbee881ce0@haskell.org> References: <046.6053a1925ff3f9f709d272bbee881ce0@haskell.org> Message-ID: <061.e84522f89998899c91a4f99a9cb3091f@haskell.org> #7544: GHC downloads are unsigned --------------------------------------------+--------------------------- Reporter: afcowie | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | --------------------------------------------+--------------------------- Comment (by hvr): Replying to [comment:5 nomeata]: > GPG signatures would still be nice. For example uscan, the tool Debian uses to download upstream tarballs, can automatically verify them by including the corresponding key in the Debian packaging meta-data. fwiw, the announcement contained GPG-signed hashes: http://www.haskell.org/pipermail/glasgow-haskell- users/2014-July/025105.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 00:10:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 00:10:52 -0000 Subject: [GHC] #9633: PolyKinds in 7.8.2 vs 7.8.3 In-Reply-To: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> References: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> Message-ID: <062.06c12750924f51387d53858eafce2d31@haskell.org> #9633: PolyKinds in 7.8.2 vs 7.8.3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PolyKinds Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by crockeea: Old description: > The following code '''compiles''' with GHC 7.8.2. > > > This code has been distilled down from a larger example where I needed > `-XPolyKinds` in Bar.hs but not in Foo.hs. In addition, the `modify` > function is supposed to modify a mutable `Data.Vector`, hence the inner > `go` function has the intended type of `Int -> m ()`, though strictly > speaking it could return any value since everything is discarded by the > `forM_`. > > {{{ > -- {-# LANGUAGE PolyKinds #-} > > module Foo where > > import Control.Monad (forM_) > import Control.Monad.Primitive > > import Bar > > -- Vector signatures > unsafeRead :: (PrimMonad m) => v (PrimState m) a -> Int -> m a > unsafeRead = error "type only" > unsafeWrite :: (PrimMonad m) => v (PrimState m) a -> Int -> a -> m () > unsafeWrite = error "type only" > > modify :: Int -> Bar v r > modify p = Bar (p-1) $ \y -> do > let go i = do > a <- unsafeRead y i > unsafeWrite y i a > --return a > forM_ [0..(p-1)] go > }}} > > {{{ > {-# LANGUAGE RankNTypes, PolyKinds #-} > module Bar where > > import Control.Monad.Primitive > > data Bar v r = Bar Int (forall s . (PrimMonad s) => v (PrimState s) r -> > s ()) > }}} > > In 7.8.3, this above code results in the error (with `-fprint-explicit- > kinds`) > > {{{ > Foo.hs:19:23: > Couldn't match type ?a0? with ?r? > ?a0? is untouchable > inside the constraints (PrimMonad m, > (~) * (PrimState m) (PrimState s)) > bound by the inferred type of > go :: (PrimMonad m, (~) * (PrimState m) (PrimState s)) > => > Int -> m () > at Foo.hs:(18,7)-(20,23) > ?r? is a rigid type variable bound by > the type signature for modify :: Int -> Bar * v r at > Foo.hs:16:11 > Expected type: v0 (PrimState m) a0 > Actual type: v (PrimState s) r > ... > In the first argument of ?unsafeRead?, namely ?y? > In a stmt of a 'do' block: a <- unsafeRead y i > > Foo.hs:20:19: > Couldn't match type ?v1? with ?v? > ?v1? is untouchable > inside the constraints (PrimMonad m, > (~) * (PrimState m) (PrimState s)) > bound by the inferred type of > go :: (PrimMonad m, (~) * (PrimState m) (PrimState s)) > => > Int -> m () > at Foo.hs:(18,7)-(20,23) > ?v? is a rigid type variable bound by > the type signature for modify :: Int -> Bar * v r at > Foo.hs:16:11 > Expected type: v1 (PrimState m) a0 > Actual type: v (PrimState s) r > ... > In the first argument of ?unsafeWrite?, namely ?y? > ... > Failed, modules loaded: Bar. > }}} > > After much digging, I found that enabling `-XPolyKinds` in Foo.hs gives a > more meaningful error: > > {{{ > Foo.hs:19:23: > Could not deduce ((~) (* -> k -> *) v v0) > ... > Expected type: v0 (PrimState m) a0 > Actual type: v (PrimState s) r > ... > In the first argument of ?unsafeRead?, namely ?y? > In a stmt of a 'do' block: a <- unsafeRead y i > > Foo.hs:20:19: > Could not deduce ((~) (* -> k -> *) v v1) > ... > Expected type: v1 (PrimState m) a0 > Actual type: v (PrimState s) r > ... > In the first argument of ?unsafeWrite?, namely ?y? > In a stmt of a 'do' block: unsafeWrite y i a > Failed, modules loaded: Bar. > }}} > > Adding `PolyKinds` to Foo.hs ''and'' uncommenting `return a` results in > the error: > > {{{ > Foo.hs:17:12: > Couldn't match kind ?k? with ?k1? > because type variable ?k1? would escape its scope > This (rigid, skolem) type variable is bound by > the type signature for modify :: Int -> Bar k1 v r > at Foo.hs:16:11-24 > Expected type: Bar k1 v r > Actual type: Bar k v0 r0 > ... > In the expression: > Bar (p - 1) > $ \ y > -> do { let ...; > forM_ [0 .. (p - 1)] go } > ... > > Foo.hs:18:7: > Kind incompatibility when matching types: > v0 :: * -> k -> * > v1 :: * -> * -> * > ... > When checking that ?go? > has the inferred type ?forall (k :: BOX) > (m :: * -> *) > b > (v :: * -> * -> *) > (v1 :: * -> * -> *). > ((~) (* -> k -> *) v0 v, (~) k r0 b, (~) (* > -> k -> *) v0 v1, > PrimMonad m, (~) * (PrimState m) (PrimState > s)) => > Int -> m b? > Probable cause: the inferred type is ambiguous > In the expression: > do { let go i = ...; > forM_ [0 .. (p - 1)] go } > ... > Failed, modules loaded: Bar. > > }}} > > These errors can be resolved by modifying the original code above in any > of the following ways: > > 1. Remove `-XPolyKinds` from Bar.hs > 2. Add an explicit kind signature to the `v :: * -> * -> *` parameter of > type `Bar` > 3. With `PolyKinds` in Bar but *not* Foo, uncommenting `return a` make > GHC 7.8.3. compile > > What I'm trying to understand is > 1. Why there is different behavior from 7.8.2 to 7.8.3. There doesn't > seem to be anything addressing `PolyKinds` in the > [http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/release-7-8-3.html > release notes vs 7.8.2] . > 2. In the event the above code should not compile with 7.8.3, there > error message could be much clearer. The first error message above didn't > help me understand that `PolyKinds` was to blame, while the second error > did a better job, and the third was very clearly a `PolyKinds` issue > (i.e. `kind mismatch`) > 3. For the third resolution option above, I can't see any reason that > adding `return a` to the inner `go` function should make the code compile > while leaving it out makes the code somehow ambiguous. This, if nothing > else, seems like a bug. New description: The following code '''compiles''' with GHC 7.8.2. This code has been distilled down from a larger example where I needed `-XPolyKinds` in Bar.hs but not in Foo.hs. In addition, the `modify` function is supposed to modify a mutable `Data.Vector`, hence the inner `go` function has the intended type of `Int -> m ()`, though strictly speaking it could return any value since everything is discarded by the `forM_`. {{{ -- {-# LANGUAGE PolyKinds #-} module Foo where import Control.Monad (forM_) import Bar -- Vector signatures unsafeRead :: (PrimMonad m) => v (PrimState m) a -> Int -> m a unsafeRead = error "type only" unsafeWrite :: (PrimMonad m) => v (PrimState m) a -> Int -> a -> m () unsafeWrite = error "type only" modify :: Int -> Bar v r modify p = Bar (p-1) $ \y -> do let go i = do a <- unsafeRead y i unsafeWrite y i a --return a forM_ [0..(p-1)] go }}} {{{ {-# LANGUAGE RankNTypes, KindSignatures, TypeFamilies, PolyKinds #-} module Bar where class Monad m => PrimMonad (m :: * -> *) where type family PrimState (m :: * -> *) :: * data Bar v r = Bar Int (forall s . (PrimMonad s) => v (PrimState s) r -> s ()) }}} In 7.8.3, this above code results in the error (with `-fprint-explicit- kinds`) {{{ Foo.hs:19:23: Couldn't match type ?a0? with ?r? ?a0? is untouchable inside the constraints (PrimMonad m, (~) * (PrimState m) (PrimState s)) bound by the inferred type of go :: (PrimMonad m, (~) * (PrimState m) (PrimState s)) => Int -> m () at Foo.hs:(18,7)-(20,23) ?r? is a rigid type variable bound by the type signature for modify :: Int -> Bar * v r at Foo.hs:16:11 Expected type: v0 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeRead?, namely ?y? In a stmt of a 'do' block: a <- unsafeRead y i Foo.hs:20:19: Couldn't match type ?v1? with ?v? ?v1? is untouchable inside the constraints (PrimMonad m, (~) * (PrimState m) (PrimState s)) bound by the inferred type of go :: (PrimMonad m, (~) * (PrimState m) (PrimState s)) => Int -> m () at Foo.hs:(18,7)-(20,23) ?v? is a rigid type variable bound by the type signature for modify :: Int -> Bar * v r at Foo.hs:16:11 Expected type: v1 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeWrite?, namely ?y? ... Failed, modules loaded: Bar. }}} After much digging, I found that enabling `-XPolyKinds` in Foo.hs gives a more meaningful error: {{{ Foo.hs:19:23: Could not deduce ((~) (* -> k -> *) v v0) ... Expected type: v0 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeRead?, namely ?y? In a stmt of a 'do' block: a <- unsafeRead y i Foo.hs:20:19: Could not deduce ((~) (* -> k -> *) v v1) ... Expected type: v1 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeWrite?, namely ?y? In a stmt of a 'do' block: unsafeWrite y i a Failed, modules loaded: Bar. }}} Adding `PolyKinds` to Foo.hs ''and'' uncommenting `return a` results in the error: {{{ Foo.hs:17:12: Couldn't match kind ?k? with ?k1? because type variable ?k1? would escape its scope This (rigid, skolem) type variable is bound by the type signature for modify :: Int -> Bar k1 v r at Foo.hs:16:11-24 Expected type: Bar k1 v r Actual type: Bar k v0 r0 ... In the expression: Bar (p - 1) $ \ y -> do { let ...; forM_ [0 .. (p - 1)] go } ... Foo.hs:18:7: Kind incompatibility when matching types: v0 :: * -> k -> * v1 :: * -> * -> * ... When checking that ?go? has the inferred type ?forall (k :: BOX) (m :: * -> *) b (v :: * -> * -> *) (v1 :: * -> * -> *). ((~) (* -> k -> *) v0 v, (~) k r0 b, (~) (* -> k -> *) v0 v1, PrimMonad m, (~) * (PrimState m) (PrimState s)) => Int -> m b? Probable cause: the inferred type is ambiguous In the expression: do { let go i = ...; forM_ [0 .. (p - 1)] go } ... Failed, modules loaded: Bar. }}} These errors can be resolved by modifying the original code above in any of the following ways: 1. Remove `-XPolyKinds` from Bar.hs 2. Add an explicit kind signature to the `v :: * -> * -> *` parameter of type `Bar` 3. With `PolyKinds` in Bar but *not* Foo, uncommenting `return a` make GHC 7.8.3. compile What I'm trying to understand is 1. Why there is different behavior from 7.8.2 to 7.8.3. There doesn't seem to be anything addressing `PolyKinds` in the [http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/release-7-8-3.html release notes vs 7.8.2] . 2. In the event the above code should not compile with 7.8.3, there error message could be much clearer. The first error message above didn't help me understand that `PolyKinds` was to blame, while the second error did a better job, and the third was very clearly a `PolyKinds` issue (i.e. `kind mismatch`) 3. For the third resolution option above, I can't see any reason that adding `return a` to the inner `go` function should make the code compile while leaving it out makes the code somehow ambiguous. This, if nothing else, seems like a bug. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 00:13:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 00:13:28 -0000 Subject: [GHC] #9633: PolyKinds in 7.8.2 vs 7.8.3 In-Reply-To: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> References: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> Message-ID: <062.ae53dbe77324a5468ad8ce08fbbbc0e5@haskell.org> #9633: PolyKinds in 7.8.2 vs 7.8.3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PolyKinds Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by crockeea: Old description: > The following code '''compiles''' with GHC 7.8.2. > > > This code has been distilled down from a larger example where I needed > `-XPolyKinds` in Bar.hs but not in Foo.hs. In addition, the `modify` > function is supposed to modify a mutable `Data.Vector`, hence the inner > `go` function has the intended type of `Int -> m ()`, though strictly > speaking it could return any value since everything is discarded by the > `forM_`. > > {{{ > -- {-# LANGUAGE PolyKinds #-} > > module Foo where > > import Control.Monad (forM_) > import Bar > > -- Vector signatures > unsafeRead :: (PrimMonad m) => v (PrimState m) a -> Int -> m a > unsafeRead = error "type only" > unsafeWrite :: (PrimMonad m) => v (PrimState m) a -> Int -> a -> m () > unsafeWrite = error "type only" > > modify :: Int -> Bar v r > modify p = Bar (p-1) $ \y -> do > let go i = do > a <- unsafeRead y i > unsafeWrite y i a > --return a > forM_ [0..(p-1)] go > }}} > > {{{ > {-# LANGUAGE RankNTypes, KindSignatures, TypeFamilies, PolyKinds #-} > module Bar where > > class Monad m => PrimMonad (m :: * -> *) where > type family PrimState (m :: * -> *) :: * > > data Bar v r = Bar Int (forall s . (PrimMonad s) => v (PrimState s) r -> > s ()) > }}} > > In 7.8.3, this above code results in the error (with `-fprint-explicit- > kinds`) > > {{{ > Foo.hs:19:23: > Couldn't match type ?a0? with ?r? > ?a0? is untouchable > inside the constraints (PrimMonad m, > (~) * (PrimState m) (PrimState s)) > bound by the inferred type of > go :: (PrimMonad m, (~) * (PrimState m) (PrimState s)) > => > Int -> m () > at Foo.hs:(18,7)-(20,23) > ?r? is a rigid type variable bound by > the type signature for modify :: Int -> Bar * v r at > Foo.hs:16:11 > Expected type: v0 (PrimState m) a0 > Actual type: v (PrimState s) r > ... > In the first argument of ?unsafeRead?, namely ?y? > In a stmt of a 'do' block: a <- unsafeRead y i > > Foo.hs:20:19: > Couldn't match type ?v1? with ?v? > ?v1? is untouchable > inside the constraints (PrimMonad m, > (~) * (PrimState m) (PrimState s)) > bound by the inferred type of > go :: (PrimMonad m, (~) * (PrimState m) (PrimState s)) > => > Int -> m () > at Foo.hs:(18,7)-(20,23) > ?v? is a rigid type variable bound by > the type signature for modify :: Int -> Bar * v r at > Foo.hs:16:11 > Expected type: v1 (PrimState m) a0 > Actual type: v (PrimState s) r > ... > In the first argument of ?unsafeWrite?, namely ?y? > ... > Failed, modules loaded: Bar. > }}} > > After much digging, I found that enabling `-XPolyKinds` in Foo.hs gives a > more meaningful error: > > {{{ > Foo.hs:19:23: > Could not deduce ((~) (* -> k -> *) v v0) > ... > Expected type: v0 (PrimState m) a0 > Actual type: v (PrimState s) r > ... > In the first argument of ?unsafeRead?, namely ?y? > In a stmt of a 'do' block: a <- unsafeRead y i > > Foo.hs:20:19: > Could not deduce ((~) (* -> k -> *) v v1) > ... > Expected type: v1 (PrimState m) a0 > Actual type: v (PrimState s) r > ... > In the first argument of ?unsafeWrite?, namely ?y? > In a stmt of a 'do' block: unsafeWrite y i a > Failed, modules loaded: Bar. > }}} > > Adding `PolyKinds` to Foo.hs ''and'' uncommenting `return a` results in > the error: > > {{{ > Foo.hs:17:12: > Couldn't match kind ?k? with ?k1? > because type variable ?k1? would escape its scope > This (rigid, skolem) type variable is bound by > the type signature for modify :: Int -> Bar k1 v r > at Foo.hs:16:11-24 > Expected type: Bar k1 v r > Actual type: Bar k v0 r0 > ... > In the expression: > Bar (p - 1) > $ \ y > -> do { let ...; > forM_ [0 .. (p - 1)] go } > ... > > Foo.hs:18:7: > Kind incompatibility when matching types: > v0 :: * -> k -> * > v1 :: * -> * -> * > ... > When checking that ?go? > has the inferred type ?forall (k :: BOX) > (m :: * -> *) > b > (v :: * -> * -> *) > (v1 :: * -> * -> *). > ((~) (* -> k -> *) v0 v, (~) k r0 b, (~) (* > -> k -> *) v0 v1, > PrimMonad m, (~) * (PrimState m) (PrimState > s)) => > Int -> m b? > Probable cause: the inferred type is ambiguous > In the expression: > do { let go i = ...; > forM_ [0 .. (p - 1)] go } > ... > Failed, modules loaded: Bar. > > }}} > > These errors can be resolved by modifying the original code above in any > of the following ways: > > 1. Remove `-XPolyKinds` from Bar.hs > 2. Add an explicit kind signature to the `v :: * -> * -> *` parameter of > type `Bar` > 3. With `PolyKinds` in Bar but *not* Foo, uncommenting `return a` make > GHC 7.8.3. compile > > What I'm trying to understand is > 1. Why there is different behavior from 7.8.2 to 7.8.3. There doesn't > seem to be anything addressing `PolyKinds` in the > [http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/release-7-8-3.html > release notes vs 7.8.2] . > 2. In the event the above code should not compile with 7.8.3, there > error message could be much clearer. The first error message above didn't > help me understand that `PolyKinds` was to blame, while the second error > did a better job, and the third was very clearly a `PolyKinds` issue > (i.e. `kind mismatch`) > 3. For the third resolution option above, I can't see any reason that > adding `return a` to the inner `go` function should make the code compile > while leaving it out makes the code somehow ambiguous. This, if nothing > else, seems like a bug. New description: The following code '''compiles''' with GHC 7.8.2. This code has been distilled down from a larger example where I needed `-XPolyKinds` in Bar.hs but not in Foo.hs. In addition, the `modify` function is supposed to modify a mutable `Data.Vector`, hence the inner `go` function has the intended type of `Int -> m ()`, though strictly speaking it could return any value since everything is discarded by the `forM_`. {{{ -- {-# LANGUAGE PolyKinds #-} module Foo where import Control.Monad (forM_) import Bar -- Vector signatures unsafeRead :: (Monad m) => v (PrimState m) a -> Int -> m a unsafeRead = error "type only" unsafeWrite :: (Monad m) => v (PrimState m) a -> Int -> a -> m () unsafeWrite = error "type only" modify :: Int -> Bar v r modify p = Bar (p-1) $ \y -> do let go i = do a <- unsafeRead y i unsafeWrite y i a --return a forM_ [0..(p-1)] go }}} {{{ {-# LANGUAGE RankNTypes, KindSignatures, TypeFamilies, PolyKinds #-} module Bar where type family PrimState (m :: * -> *) :: * data Bar v r = Bar Int (forall s . (Monad s) => v (PrimState s) r -> s ()) }}} In 7.8.3, this above code results in the error (with `-fprint-explicit- kinds`) {{{ Foo.hs:19:23: Couldn't match type ?a0? with ?r? ?a0? is untouchable inside the constraints (Monad m, (~) * (PrimState m) (PrimState s)) bound by the inferred type of go :: (Monad m, (~) * (PrimState m) (PrimState s)) => Int -> m () at Foo.hs:(18,7)-(20,23) ?r? is a rigid type variable bound by the type signature for modify :: Int -> Bar * v r at Foo.hs:16:11 Expected type: v0 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeRead?, namely ?y? In a stmt of a 'do' block: a <- unsafeRead y i Foo.hs:20:19: Couldn't match type ?v1? with ?v? ?v1? is untouchable inside the constraints (Monad m, (~) * (PrimState m) (PrimState s)) bound by the inferred type of go :: (Monad m, (~) * (PrimState m) (PrimState s)) => Int -> m () at Foo.hs:(18,7)-(20,23) ?v? is a rigid type variable bound by the type signature for modify :: Int -> Bar * v r at Foo.hs:16:11 Expected type: v1 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeWrite?, namely ?y? ... Failed, modules loaded: Bar. }}} After much digging, I found that enabling `-XPolyKinds` in Foo.hs gives a more meaningful error: {{{ Foo.hs:19:23: Could not deduce ((~) (* -> k -> *) v v0) ... Expected type: v0 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeRead?, namely ?y? In a stmt of a 'do' block: a <- unsafeRead y i Foo.hs:20:19: Could not deduce ((~) (* -> k -> *) v v1) ... Expected type: v1 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeWrite?, namely ?y? In a stmt of a 'do' block: unsafeWrite y i a Failed, modules loaded: Bar. }}} Adding `PolyKinds` to Foo.hs ''and'' uncommenting `return a` results in the error: {{{ Foo.hs:17:12: Couldn't match kind ?k? with ?k1? because type variable ?k1? would escape its scope This (rigid, skolem) type variable is bound by the type signature for modify :: Int -> Bar k1 v r at Foo.hs:16:11-24 Expected type: Bar k1 v r Actual type: Bar k v0 r0 ... In the expression: Bar (p - 1) $ \ y -> do { let ...; forM_ [0 .. (p - 1)] go } ... Foo.hs:18:7: Kind incompatibility when matching types: v0 :: * -> k -> * v1 :: * -> * -> * ... When checking that ?go? has the inferred type ?forall (k :: BOX) (m :: * -> *) b (v :: * -> * -> *) (v1 :: * -> * -> *). ((~) (* -> k -> *) v0 v, (~) k r0 b, (~) (* -> k -> *) v0 v1, PrimMonad m, (~) * (PrimState m) (PrimState s)) => Int -> m b? Probable cause: the inferred type is ambiguous In the expression: do { let go i = ...; forM_ [0 .. (p - 1)] go } ... Failed, modules loaded: Bar. }}} These errors can be resolved by modifying the original code above in any of the following ways: 1. Remove `-XPolyKinds` from Bar.hs 2. Add an explicit kind signature to the `v :: * -> * -> *` parameter of type `Bar` 3. With `PolyKinds` in Bar but *not* Foo, uncommenting `return a` make GHC 7.8.3. compile What I'm trying to understand is 1. Why there is different behavior from 7.8.2 to 7.8.3. There doesn't seem to be anything addressing `PolyKinds` in the [http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/release-7-8-3.html release notes vs 7.8.2] . 2. In the event the above code should not compile with 7.8.3, there error message could be much clearer. The first error message above didn't help me understand that `PolyKinds` was to blame, while the second error did a better job, and the third was very clearly a `PolyKinds` issue (i.e. `kind mismatch`) 3. For the third resolution option above, I can't see any reason that adding `return a` to the inner `go` function should make the code compile while leaving it out makes the code somehow ambiguous. This, if nothing else, seems like a bug. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 00:14:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 00:14:37 -0000 Subject: [GHC] #9633: PolyKinds in 7.8.2 vs 7.8.3 In-Reply-To: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> References: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> Message-ID: <062.379cc24234ea32d40492d1ddee218858@haskell.org> #9633: PolyKinds in 7.8.2 vs 7.8.3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PolyKinds Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by crockeea: Old description: > The following code '''compiles''' with GHC 7.8.2. > > > This code has been distilled down from a larger example where I needed > `-XPolyKinds` in Bar.hs but not in Foo.hs. In addition, the `modify` > function is supposed to modify a mutable `Data.Vector`, hence the inner > `go` function has the intended type of `Int -> m ()`, though strictly > speaking it could return any value since everything is discarded by the > `forM_`. > > {{{ > -- {-# LANGUAGE PolyKinds #-} > > module Foo where > > import Control.Monad (forM_) > import Bar > > -- Vector signatures > unsafeRead :: (Monad m) => v (PrimState m) a -> Int -> m a > unsafeRead = error "type only" > unsafeWrite :: (Monad m) => v (PrimState m) a -> Int -> a -> m () > unsafeWrite = error "type only" > > modify :: Int -> Bar v r > modify p = Bar (p-1) $ \y -> do > let go i = do > a <- unsafeRead y i > unsafeWrite y i a > --return a > forM_ [0..(p-1)] go > }}} > > {{{ > {-# LANGUAGE RankNTypes, KindSignatures, TypeFamilies, PolyKinds #-} > module Bar where > > type family PrimState (m :: * -> *) :: * > > data Bar v r = Bar Int (forall s . (Monad s) => v (PrimState s) r -> s > ()) > }}} > > In 7.8.3, this above code results in the error (with `-fprint-explicit- > kinds`) > > {{{ > Foo.hs:19:23: > Couldn't match type ?a0? with ?r? > ?a0? is untouchable > inside the constraints (Monad m, > (~) * (PrimState m) (PrimState s)) > bound by the inferred type of > go :: (Monad m, (~) * (PrimState m) (PrimState s)) => > Int -> m () > at Foo.hs:(18,7)-(20,23) > ?r? is a rigid type variable bound by > the type signature for modify :: Int -> Bar * v r at > Foo.hs:16:11 > Expected type: v0 (PrimState m) a0 > Actual type: v (PrimState s) r > ... > In the first argument of ?unsafeRead?, namely ?y? > In a stmt of a 'do' block: a <- unsafeRead y i > > Foo.hs:20:19: > Couldn't match type ?v1? with ?v? > ?v1? is untouchable > inside the constraints (Monad m, > (~) * (PrimState m) (PrimState s)) > bound by the inferred type of > go :: (Monad m, (~) * (PrimState m) (PrimState s)) => > Int -> m () > at Foo.hs:(18,7)-(20,23) > ?v? is a rigid type variable bound by > the type signature for modify :: Int -> Bar * v r at > Foo.hs:16:11 > Expected type: v1 (PrimState m) a0 > Actual type: v (PrimState s) r > ... > In the first argument of ?unsafeWrite?, namely ?y? > ... > Failed, modules loaded: Bar. > }}} > > After much digging, I found that enabling `-XPolyKinds` in Foo.hs gives a > more meaningful error: > > {{{ > Foo.hs:19:23: > Could not deduce ((~) (* -> k -> *) v v0) > ... > Expected type: v0 (PrimState m) a0 > Actual type: v (PrimState s) r > ... > In the first argument of ?unsafeRead?, namely ?y? > In a stmt of a 'do' block: a <- unsafeRead y i > > Foo.hs:20:19: > Could not deduce ((~) (* -> k -> *) v v1) > ... > Expected type: v1 (PrimState m) a0 > Actual type: v (PrimState s) r > ... > In the first argument of ?unsafeWrite?, namely ?y? > In a stmt of a 'do' block: unsafeWrite y i a > Failed, modules loaded: Bar. > }}} > > Adding `PolyKinds` to Foo.hs ''and'' uncommenting `return a` results in > the error: > > {{{ > Foo.hs:17:12: > Couldn't match kind ?k? with ?k1? > because type variable ?k1? would escape its scope > This (rigid, skolem) type variable is bound by > the type signature for modify :: Int -> Bar k1 v r > at Foo.hs:16:11-24 > Expected type: Bar k1 v r > Actual type: Bar k v0 r0 > ... > In the expression: > Bar (p - 1) > $ \ y > -> do { let ...; > forM_ [0 .. (p - 1)] go } > ... > > Foo.hs:18:7: > Kind incompatibility when matching types: > v0 :: * -> k -> * > v1 :: * -> * -> * > ... > When checking that ?go? > has the inferred type ?forall (k :: BOX) > (m :: * -> *) > b > (v :: * -> * -> *) > (v1 :: * -> * -> *). > ((~) (* -> k -> *) v0 v, (~) k r0 b, (~) (* > -> k -> *) v0 v1, > PrimMonad m, (~) * (PrimState m) (PrimState > s)) => > Int -> m b? > Probable cause: the inferred type is ambiguous > In the expression: > do { let go i = ...; > forM_ [0 .. (p - 1)] go } > ... > Failed, modules loaded: Bar. > > }}} > > These errors can be resolved by modifying the original code above in any > of the following ways: > > 1. Remove `-XPolyKinds` from Bar.hs > 2. Add an explicit kind signature to the `v :: * -> * -> *` parameter of > type `Bar` > 3. With `PolyKinds` in Bar but *not* Foo, uncommenting `return a` make > GHC 7.8.3. compile > > What I'm trying to understand is > 1. Why there is different behavior from 7.8.2 to 7.8.3. There doesn't > seem to be anything addressing `PolyKinds` in the > [http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/release-7-8-3.html > release notes vs 7.8.2] . > 2. In the event the above code should not compile with 7.8.3, there > error message could be much clearer. The first error message above didn't > help me understand that `PolyKinds` was to blame, while the second error > did a better job, and the third was very clearly a `PolyKinds` issue > (i.e. `kind mismatch`) > 3. For the third resolution option above, I can't see any reason that > adding `return a` to the inner `go` function should make the code compile > while leaving it out makes the code somehow ambiguous. This, if nothing > else, seems like a bug. New description: The following code '''compiles''' with GHC 7.8.2. This code has been distilled down from a larger example where I needed `-XPolyKinds` in Bar.hs but not in Foo.hs. In addition, the `modify` function is supposed to modify a mutable `Data.Vector`, hence the inner `go` function has the intended type of `Int -> m ()`, though strictly speaking it could return any value since everything is discarded by the `forM_`. {{{ -- {-# LANGUAGE PolyKinds #-} module Foo where import Control.Monad (forM_) import Bar -- Vector signatures unsafeRead :: (Monad m) => v (PrimState m) a -> Int -> m a unsafeRead = error "type only" unsafeWrite :: (Monad m) => v (PrimState m) a -> Int -> a -> m () unsafeWrite = error "type only" modify :: Int -> Bar v r modify p = Bar (p-1) $ \y -> do let go i = do a <- unsafeRead y i unsafeWrite y i a --return a forM_ [0..(p-1)] go }}} {{{ {-# LANGUAGE RankNTypes, KindSignatures, TypeFamilies, PolyKinds #-} module Bar where type family PrimState (m :: * -> *) :: * data Bar v r = Bar Int (forall s . (Monad s) => v (PrimState s) r -> s ()) }}} In 7.8.3, this above code results in the error (with `-fprint-explicit- kinds`) {{{ Foo.hs:19:23: Couldn't match type ?a0? with ?r? ?a0? is untouchable inside the constraints (Monad m, (~) * (PrimState m) (PrimState s)) bound by the inferred type of go :: (Monad m, (~) * (PrimState m) (PrimState s)) => Int -> m () at Foo.hs:(18,7)-(20,23) ?r? is a rigid type variable bound by the type signature for modify :: Int -> Bar * v r at Foo.hs:16:11 Expected type: v0 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeRead?, namely ?y? In a stmt of a 'do' block: a <- unsafeRead y i Foo.hs:20:19: Couldn't match type ?v1? with ?v? ?v1? is untouchable inside the constraints (Monad m, (~) * (PrimState m) (PrimState s)) bound by the inferred type of go :: (Monad m, (~) * (PrimState m) (PrimState s)) => Int -> m () at Foo.hs:(18,7)-(20,23) ?v? is a rigid type variable bound by the type signature for modify :: Int -> Bar * v r at Foo.hs:16:11 Expected type: v1 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeWrite?, namely ?y? ... Failed, modules loaded: Bar. }}} After much digging, I found that enabling `-XPolyKinds` in Foo.hs gives a more meaningful error: {{{ Foo.hs:19:23: Could not deduce ((~) (* -> k -> *) v v0) ... Expected type: v0 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeRead?, namely ?y? In a stmt of a 'do' block: a <- unsafeRead y i Foo.hs:20:19: Could not deduce ((~) (* -> k -> *) v v1) ... Expected type: v1 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ?unsafeWrite?, namely ?y? In a stmt of a 'do' block: unsafeWrite y i a Failed, modules loaded: Bar. }}} Adding `PolyKinds` to Foo.hs ''and'' uncommenting `return a` results in the error: {{{ Foo.hs:17:12: Couldn't match kind ?k? with ?k1? because type variable ?k1? would escape its scope This (rigid, skolem) type variable is bound by the type signature for modify :: Int -> Bar k1 v r at Foo.hs:16:11-24 Expected type: Bar k1 v r Actual type: Bar k v0 r0 ... In the expression: Bar (p - 1) $ \ y -> do { let ...; forM_ [0 .. (p - 1)] go } ... Foo.hs:18:7: Kind incompatibility when matching types: v0 :: * -> k -> * v1 :: * -> * -> * ... When checking that ?go? has the inferred type ?forall (k :: BOX) (m :: * -> *) b (v :: * -> * -> *) (v1 :: * -> * -> *). ((~) (* -> k -> *) v0 v, (~) k r0 b, (~) (* -> k -> *) v0 v1, Monad m, (~) * (PrimState m) (PrimState s)) => Int -> m b? Probable cause: the inferred type is ambiguous In the expression: do { let go i = ...; forM_ [0 .. (p - 1)] go } ... Failed, modules loaded: Bar. }}} These errors can be resolved by modifying the original code above in any of the following ways: 1. Remove `-XPolyKinds` from Bar.hs 2. Add an explicit kind signature to the `v :: * -> * -> *` parameter of type `Bar` 3. With `PolyKinds` in Bar but *not* Foo, uncommenting `return a` make GHC 7.8.3. compile What I'm trying to understand is 1. Why there is different behavior from 7.8.2 to 7.8.3. There doesn't seem to be anything addressing `PolyKinds` in the [http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/release-7-8-3.html release notes vs 7.8.2] . 2. In the event the above code should not compile with 7.8.3, there error message could be much clearer. The first error message above didn't help me understand that `PolyKinds` was to blame, while the second error did a better job, and the third was very clearly a `PolyKinds` issue (i.e. `kind mismatch`) 3. For the third resolution option above, I can't see any reason that adding `return a` to the inner `go` function should make the code compile while leaving it out makes the code somehow ambiguous. This, if nothing else, seems like a bug. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 00:23:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 00:23:00 -0000 Subject: [GHC] #8593: vector is being built even with `--no-dph` In-Reply-To: <046.299b1f7d2da2e7b67d43549a9011b54e@haskell.org> References: <046.299b1f7d2da2e7b67d43549a9011b54e@haskell.org> Message-ID: <061.4b0765c6165967a3be61145a432df576@haskell.org> #8593: vector is being built even with `--no-dph` -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: closed request | Milestone: Priority: low | Version: 7.7 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: I just did a fresh build, with the BUILD_DPH=NO setting introduced in 88d85aa65ea15d984bf207f82d99928eda0b6c26. The libraries `vector`, `primitive` and `random` did not get built (i.e. there is not `dist- install` directory in those directories afterwards). There are however certain tests that require those libraries using `reqlib`, so they will get built when running validate I assume. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 00:45:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 00:45:19 -0000 Subject: [GHC] #9634: "data X = 1": "Illegal literal in type (use DataKinds to enable): 1" Message-ID: <047.6134223b064e72f268ea2b13c82d2523@haskell.org> #9634: "data X = 1": "Illegal literal in type (use DataKinds to enable): 1" -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This error message is not good. "1" is not in a type position, and DataKinds will not help anything. Well, except the error message, which with DataKinds enabled is instead {{{ parse error in constructor in data/newtype declaration: 1 }}} If it's not hard, we should give that error message also when DataKinds is disabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 00:52:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 00:52:32 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.4ed9d59823109528e1b4a2bbbaffe3b2@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:9 nomeata]: > (Even more crazy idea: One can even take this further. What about `case x of Right str -> Just str`. `Right` and `Just` can be used interchangeable at runtime (same constructor number, same number of arguments of the same shape). The compiler could create only one constructor for each such shape, and optimize the code above to `case x of Right _ -> x`. Furthermore we could have representational coercions between datatypes that are ?-equal... Although I doubt that the run-time benefit of that will be high, and we?d lose all hopes to implement something like `vacuum` or `ghc-vis`.) This could make `toInteger :: Int -> Integer` a no-op, for example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 03:10:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 03:10:33 -0000 Subject: [GHC] #9635: "Module imports form a cycle" on OS X Message-ID: <046.c3ba64a2f42d926bb837dcc26d8dbab7@haskell.org> #9635: "Module imports form a cycle" on OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Easy (less than 1 | GHC failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I ran into this while building GHC HEAD on OS X: {{{ Module imports form a cycle: module ?Control.Applicative? (libraries/base/Control/Applicative.hs) imports ?Control.Arrow? (libraries/base/Control/Arrow.hs) which imports ?Control.Monad.Fix? (libraries/base/Control/Monad/Fix.hs) which imports ?System.IO? (libraries/base/System/IO.hs) which imports ?GHC.IO.FD? (libraries/base/GHC/IO/FD.hs) which imports ?GHC.Conc.IO? (libraries/base/GHC/Conc/IO.hs) which imports ?GHC.Event.Thread? (libraries/base/GHC/Event/Thread.hs) which imports ?GHC.Event.Manager? (libraries/base/GHC/Event/Manager.hs) which imports ?GHC.Event.KQueue? (libraries/base/dist- install/build/GHC/Event/KQueue.hs) which imports ?Control.Monad? (libraries/base/Control/Monad.hs) which imports ?Data.Traversable? (libraries/base/Data/Traversable.hs) which imports ?Control.Applicative? (libraries/base/Control/Applicative.hs) make[1]: *** [libraries/base/dist-install/build/.depend-v-dyn.haskell] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 03:11:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 03:11:33 -0000 Subject: [GHC] #9635: "Module imports form a cycle" on OS X In-Reply-To: <046.c3ba64a2f42d926bb837dcc26d8dbab7@haskell.org> References: <046.c3ba64a2f42d926bb837dcc26d8dbab7@haskell.org> Message-ID: <061.54536b0820335559f67a8cb75191f145@haskell.org> #9635: "Module imports form a cycle" on OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Easy (less than 1 GHC failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dalaing): * owner: => dalaing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 03:24:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 03:24:01 -0000 Subject: [GHC] #9635: "Module imports form a cycle" on OS X In-Reply-To: <046.c3ba64a2f42d926bb837dcc26d8dbab7@haskell.org> References: <046.c3ba64a2f42d926bb837dcc26d8dbab7@haskell.org> Message-ID: <061.8e8e66bf75a14a36e7ed635ea40a6048@haskell.org> #9635: "Module imports form a cycle" on OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Easy (less than 1 GHC failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | https://phabricator.haskell.org/D244| -------------------------------------+------------------------------------- Changes (by dalaing): * status: new => patch * differential: => https://phabricator.haskell.org/D244 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 03:24:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 03:24:52 -0000 Subject: [GHC] #9635: "Module imports form a cycle" on OS X In-Reply-To: <046.c3ba64a2f42d926bb837dcc26d8dbab7@haskell.org> References: <046.c3ba64a2f42d926bb837dcc26d8dbab7@haskell.org> Message-ID: <061.9a5f7f2540720835804f8b6d27264e52@haskell.org> #9635: "Module imports form a cycle" on OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Easy (less than 1 GHC failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D244 | -------------------------------------+------------------------------------- Changes (by dalaing): * differential: https://phabricator.haskell.org/D244 => Phab:D244 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 03:45:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 03:45:55 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.24f2fa562077522077a73485ce25c65b@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): could this be done ethically at the STG or CMM layer if we were able to keep enough information lying around at those layers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 04:11:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 04:11:13 -0000 Subject: [GHC] #9635: "Module imports form a cycle" on OS X In-Reply-To: <046.c3ba64a2f42d926bb837dcc26d8dbab7@haskell.org> References: <046.c3ba64a2f42d926bb837dcc26d8dbab7@haskell.org> Message-ID: <061.a5fb9776f1e60ea257f8b28d0954fee0@haskell.org> #9635: "Module imports form a cycle" on OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Easy (less than 1 GHC failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D244 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"c23beffd65fd0eb50e7fe3a53a89220252aadd74/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c23beffd65fd0eb50e7fe3a53a89220252aadd74" Fixes cyclic import on OS X(#9635) Summary: Signed-off-by: Dave Laing Test Plan: Locally tested Reviewers: thomie, austin Reviewed By: thomie, austin Subscribers: simonmar, ezyang, carter, thomie Differential Revision: https://phabricator.haskell.org/D244 GHC Trac Issues: #9635 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 07:30:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 07:30:16 -0000 Subject: [GHC] #9635: "Module imports form a cycle" on OS X In-Reply-To: <046.c3ba64a2f42d926bb837dcc26d8dbab7@haskell.org> References: <046.c3ba64a2f42d926bb837dcc26d8dbab7@haskell.org> Message-ID: <061.313a684327eab4a8d102038183f30b8b@haskell.org> #9635: "Module imports form a cycle" on OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Easy (less than 1 GHC failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D244 | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 08:07:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 08:07:39 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.d5e95b476c7c670561c6c0a5f4c3ae7e@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9583 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Might it be worth leaving a few comments in the `GBInary` class to highlight that innocently inlining those methods is dangerous? And we still don't really understand why, I think. `gget` looks as if it has lots of cpp-generated code, but the others look small. Unless the things they call are in turn INLINE. So, a good fix, but it might be worth more investigation to figure out the best way to solve this in the end. I think Pedro's goal was to eliminate all the intermediate structure. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 08:09:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 08:09:32 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.3cdf03688f425c2d8dc033d75e81987d@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): You'll need to be much more explicit before anyone is likely to venture an opinion. What is the impact of "managed separately"? What is the motivation for making a change at all? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 08:20:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 08:20:25 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.11a7b97d946be183d391678dae4b7441@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:17 carter]: > could this be done ethically at the STG or CMM layer if we were able to keep enough information lying around at those layers? Yes, I think it could; both are much less strongly typed than Core. STG would be much better than CMM. There isn't currently an STG optimisation pass, but you could add one. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 09:57:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 09:57:11 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.51cf7d662a22555c0829ce9045cdeac6@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mlen): Great to hear that. I prepared the patches to suppress tab warnings in the submodules that caused troubles. Now I got stuck while de-tabbing the testsuite, as some tests won't pass. For example there are errors about wrong std{out,err} in should_compile (and others), but I should get that working soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 10:07:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 10:07:36 -0000 Subject: [GHC] #9633: PolyKinds in 7.8.2 vs 7.8.3 In-Reply-To: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> References: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> Message-ID: <062.5e622acff7b659701bf503305bbbe729@haskell.org> #9633: PolyKinds in 7.8.2 vs 7.8.3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PolyKinds Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): This works fine in HEAD, correct? (At least it does for me.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 11:34:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 11:34:50 -0000 Subject: [GHC] #9612: Use functional dependencies to give more specific error messages In-Reply-To: <047.362c86059a829fba275fe2ef97ed7a83@haskell.org> References: <047.362c86059a829fba275fe2ef97ed7a83@haskell.org> Message-ID: <062.cf6cdc5f4a9e2a9baff03673db675410@haskell.org> #9612: Use functional dependencies to give more specific error messages -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"20632d37b5bcb68bb0ca34238f1ed49c7be3a8f7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="20632d37b5bcb68bb0ca34238f1ed49c7be3a8f7" Do not discard insoluble Derived constraints This is preparing for a fix to Trac #9612. The idea is that insoluble constraints are nice solid errors that we should not discard before we have a chance to report them. So TcRnTypes.dropDerivedWC now keeps insoluble Derived constrains, and instead TcSimplify.solve_wanteds filters them out We get somewhat better error message for kind-equality failures too. A slight downside is that to avoid *duplicate* kind-equality failures when we float a kind-incompatible equality (e.g. alpha:* ~ Int#), I've disabled constraint-floating when there are insolubles. But that in turn makes a handful of error messages a little less informative; good examples are mc21, mc22, mc25. But I am re-jigging the constraint floating machinery in another branch, which will make this go back to the way it was before. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 11:34:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 11:34:50 -0000 Subject: [GHC] #9612: Use functional dependencies to give more specific error messages In-Reply-To: <047.362c86059a829fba275fe2ef97ed7a83@haskell.org> References: <047.362c86059a829fba275fe2ef97ed7a83@haskell.org> Message-ID: <062.c17b12b0ab5e2eb5b9f5310bc5eb6b48@haskell.org> #9612: Use functional dependencies to give more specific error messages -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1a88f9a4fb373ce52284996212fc23b06848b1c0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1a88f9a4fb373ce52284996212fc23b06848b1c0" Improve error messages from functional dependencies Reponding to Trac #9612: * Track the CtOrigin of a Derived equality, arising from a functional dependency * And report it clearly in the error stream This relies on a previous commit, in which I stop dropping Derived insolubles on the floor. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 11:34:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 11:34:50 -0000 Subject: [GHC] #9576: -fdefer-type-errors doesn't defer errors from `deriving` In-Reply-To: <047.d39ce22800a74d81e08df239345f30b3@haskell.org> References: <047.d39ce22800a74d81e08df239345f30b3@haskell.org> Message-ID: <062.13748a033cc898f4eb300db52e1e9a11@haskell.org> #9576: -fdefer-type-errors doesn't defer errors from `deriving` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"74ae59896e4222a8115f5548845f13495f5bb76e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="74ae59896e4222a8115f5548845f13495f5bb76e" Defer errors in derived instances Fixes Trac #9576. Turned out to be pretty easy. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 11:34:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 11:34:50 -0000 Subject: [GHC] #9634: "data X = 1": "Illegal literal in type (use DataKinds to enable): 1" In-Reply-To: <047.6134223b064e72f268ea2b13c82d2523@haskell.org> References: <047.6134223b064e72f268ea2b13c82d2523@haskell.org> Message-ID: <062.ab4a92200e4b58389cc9d43c049f3be8@haskell.org> #9634: "data X = 1": "Illegal literal in type (use DataKinds to enable): 1" -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ac157de3cd959a18a71fa056403675e2c0563497/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ac157de3cd959a18a71fa056403675e2c0563497" Complain about illegal type literals in renamer, not parser A premature complaint was causing Trac #9634. Acutally this change also simplifies the lexer and eliminates duplication. (The renamer was already making the check, as it happens.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 11:38:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 11:38:48 -0000 Subject: [GHC] #9612: Use functional dependencies to give more specific error messages In-Reply-To: <047.362c86059a829fba275fe2ef97ed7a83@haskell.org> References: <047.362c86059a829fba275fe2ef97ed7a83@haskell.org> Message-ID: <062.f39be6d66e1a6ee6666978d209b776e9@haskell.org> #9612: Use functional dependencies to give more specific error messages -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | typecheck/should_fail/T9612 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/T9612 * resolution: => fixed Comment: Good idea, thank you. The error message is now {{{ T9612.hs:16:9: Couldn't match type ?[(Int, a)]? with ?(Int, a)? arising from a functional dependency between: constraint ?MonadWriter (Int, a) (WriterT [(Int, a)] Identity)? arising from a use of ?tell? instance ?MonadWriter w (WriterT w m)? at T9612.hs:20:10-59 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 11:39:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 11:39:42 -0000 Subject: [GHC] #9576: -fdefer-type-errors doesn't defer errors from `deriving` In-Reply-To: <047.d39ce22800a74d81e08df239345f30b3@haskell.org> References: <047.d39ce22800a74d81e08df239345f30b3@haskell.org> Message-ID: <062.157abe9716dc1ef28f000d4ed994eedf@haskell.org> #9576: -fdefer-type-errors doesn't defer errors from `deriving` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_run/T9576 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => deriving/should_run/T9576 * resolution: => fixed Comment: Good suggestion, thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 11:40:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 11:40:45 -0000 Subject: [GHC] #9634: "data X = 1": "Illegal literal in type (use DataKinds to enable): 1" In-Reply-To: <047.6134223b064e72f268ea2b13c82d2523@haskell.org> References: <047.6134223b064e72f268ea2b13c82d2523@haskell.org> Message-ID: <062.cc1471ea425143c6d2db38ab0236cdb7@haskell.org> #9634: "data X = 1": "Illegal literal in type (use DataKinds to enable): 1" -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | typecheck/should_fail/T9634 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/T9634 * resolution: => fixed Comment: Good point, thank you. We now get {{{ T9634.hs:3:10: Cannot parse data constructor in a data/newtype declaration: 1 }}} whether or not `DataKinds` is on Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 12:18:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 12:18:55 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs In-Reply-To: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> References: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> Message-ID: <066.9c3e077f648e4d7e65799f3a20e967cb@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: patch Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: InstanceSigs (Type checker) | TypeFamilies Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): The hack is horrible! I suggest instead replacing the `CtOrigin` arg to `tcSubPat` with `BasicTypes.SwapFlag`. If `NotSwapped` then `ty1` is acutal, `ty2` is expected; if `Swapped` then the other way round. That would make all the other calls more perspicuous too. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 12:50:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 12:50:35 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.9432c065915709777c6b98bd8b3b45b7@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): Replying to [comment:29 rwbarton]: > Can't we determine the context for the derived instance from the contexts of the default method type signatures? Not really. Look at the [http://www.haskell.org/haskellwiki/GHC.Generics serialisation example from the wiki page]: {{{ putDefault :: (Generic a, GSerialize (Rep a)) => a -> [Bit] }}} Nothing here tells us that we need `Serialize` constraints on the datatype parameters. More info comes from the K1 instance, though: {{{ instance (Serialize a) => GSerialize (K1 i a) where gput (K1 x) = put x }}} Here we see that the constructor arguments will require a `Serialize` instance. So if parameter `a` appears as argument to a constructor, we should introduce the constraint `Serialize a`. But this is non-trivial in general... the constraint might be part in an instance of the form `K1 i a :*: g`, for example. I think going for Andres's proposal is still the best idea, as it is simple and relates to something people already know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 12:59:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 12:59:12 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.9c357f6bf0fee3aedaa1132a6ec316c3@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): You know what I'm going to say. Can you write a wiki page that specifies the feature, as seen by the programmer, as precisely as possible. When it is legal? What instance declaration is generated? What is the context on that instance declaration. If there are any implementation wrinkles, they can appear in a separate section on the wiki page. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 13:39:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 13:39:00 -0000 Subject: [GHC] #9633: PolyKinds in 7.8.2 vs 7.8.3 In-Reply-To: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> References: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> Message-ID: <062.b0acfbaca90c8619b673d082f0b83cfb@haskell.org> #9633: PolyKinds in 7.8.2 vs 7.8.3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PolyKinds Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Here is what is happening. * Between 7.8.2 and 7.8.3, I fixed #8985. * That meant that when typechecking `go` we get a deferred equality constraint `v ~ alpha`, where `alpha` is a unification variable, but untouchable. (Before it was (wrongly) solved on the fly by unifiying an untouchable kind variable.) * Because `TypeFamilies` and `MonoLocalBinds` are not on, we try to generalise `go`. That give it a signature like `go :: (Monad m, PrimState m ~ PrimState s) => ...blah...` * Hence we get a residual unsolved implication constraint like `(Monad m, PrimState m ~ PrimState s) => v ~ alpha`. * We can't float `v ~ alpha` out of the implication because there's an equality in the "givens". * So it never gets solved. HEAD complains instead: {{{ T9633.hs:17:7: Illegal equational constraint PrimState m ~ PrimState s (Use GADTs or TypeFamilies to permit this) When checking that ?go? has the inferred type go :: forall (m :: * -> *). (Monad m, PrimState m ~ PrimState s) => Int -> m () }}} And when you switch on `TypeFamilies` that switches on `MonoLocalBinds` which in turn means that we don't attempt to generalise `go`, and the program compiles fine. Bottom line: I don't expect most users to make sense of the above explanation, but HEAD points you in the right direction. It's an instructive case, but I don't propose to take any new action. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 13:47:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 13:47:38 -0000 Subject: [GHC] #9633: PolyKinds in 7.8.2 vs 7.8.3 In-Reply-To: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> References: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> Message-ID: <062.66d1fc1c17c6eda15cc8b0a9b8bcbe7e@haskell.org> #9633: PolyKinds in 7.8.2 vs 7.8.3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PolyKinds Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): I verified that adding `TypeFamilies` to Foo.hs in 7.8.3 makes the original example compile fine. I'm happy with the error in HEAD, so it looks like this problem will not be an issue in 7.10. Thanks for investigating Simon! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 13:50:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 13:50:05 -0000 Subject: [GHC] #9633: PolyKinds in 7.8.2 vs 7.8.3 In-Reply-To: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> References: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> Message-ID: <062.58030d06a22365cc99f4edf7ffefc9a8@haskell.org> #9633: PolyKinds in 7.8.2 vs 7.8.3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PolyKinds Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by crockeea): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 13:56:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 13:56:47 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.54253ddd9a9d01687ca83448af925a0f@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D246 | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => D246 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 13:59:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 13:59:50 -0000 Subject: [GHC] #9636: Function with type error accepted Message-ID: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following program is accepted by ghc even though it is clearly wrong. The type family T is closed so T Bool cannot ever be reduced, so it must be a type error. {{{#!hs {-# LANGUAGE TypeFamilies #-} module Err62 where type family T a where T Int = () x :: T Bool x = undefined f :: T Bool -> Bool f _ = True y :: Bool y = f x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 14:11:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 14:11:40 -0000 Subject: [GHC] #9637: Type level programming needs an error function Message-ID: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When doing type level programming you often need a way to report errors. I suggest a closed type family called Error with special semantics. It is kinded like this Error :: Symbol -> k1 -> k2 If this function has to be reduced during constraint solving it will simply generate a type error with the given string and printing the type as extra information (this kind can be generalized a lot if we want to). I've found that having this function gives more accurate and earlier error messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 14:38:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 14:38:01 -0000 Subject: [GHC] #9637: Type level programming needs an error function In-Reply-To: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> References: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> Message-ID: <062.4a6af143eceb66e39e48263d3bf33fde@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for it! Can you write a more precise specification? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 14:55:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 14:55:07 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.50d51371e7aee951b022cc1f83485abb@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well, I was imagining that you would simply reduce the constraints using whatever instances are in scope, just like when inferring the type of a top-level definition. However, now I see that this falls apart in the presence of non-uniform recursion. Quite annoying... but in this case there seems to potentially be a genuine choice involved, so it might be sensible to just reject "deriving" then and require the user to write their own instance head. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 15:11:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 15:11:34 -0000 Subject: [GHC] #9638: Speed up Data.Char.isDigit Message-ID: <045.8305c40432408fead5554261d41a3400@haskell.org> #9638: Speed up Data.Char.isDigit -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `isDigit` is currently defined like this: {{{#!hs isDigit :: Char -> Bool isDigit c = c >= '0' && c <= '9' }}} This will short-circuit the right way if you're looking for digits mixed with spaces, but the wrong way if you're looking for digits mixed with letters. It also requires a conditional jump to do that short-circuiting (confirmed by inspecting the assembly). It should be better to use an unsigned comparison instead: {{{#!hs isDigit :: Char -> Bool isDigit c = (fromIntegral (ord c) :: Word) - 48 <= 9 }}} The interesting section looks like this {{{ movq 7(%rbx),%rax addq $-48,%rax cmpq $9,%rax setbe %al movzbl %al,%eax shlq $3,%rax movq ghczmprim_GHCziTypes_Bool_closure_tbl(%rax),%rbx addq $8,%rbp jmp *(%rbp) }}} or like this with -fllvm: {{{ movq 7(%rbx), %rax addq $-48, %rax cmpq $10, %rax sbbq %rax, %rax andq $8, %rax movq ghczmprim_GHCziTypes_Bool_closure_tbl(%rax), %rbx movq 8(%rbp), %rax addq $8, %rbp jmpq *%rax # TAILCALL }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 15:19:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 15:19:28 -0000 Subject: [GHC] #3304: define gcd 0 0 = 0 In-Reply-To: <045.185c8414dc74a05b9b8c81a6506a335e@haskell.org> References: <045.185c8414dc74a05b9b8c81a6506a335e@haskell.org> Message-ID: <060.434ee391e07fcdb68a5116311b56c0c5@haskell.org> #3304: define gcd 0 0 = 0 -------------------------------------+------------------------------------- Reporter: stevec | Owner: Type: proposal | Status: closed Priority: normal | Milestone: 7.2.1 Component: | Version: 7.1 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by asr): * cc: andres.sicard.ramirez@? (removed) * cc: asr, hvr, ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 15:20:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 15:20:22 -0000 Subject: [GHC] #4284: Adding parentheses introduces type error In-Reply-To: <049.4776fec4b1507e73e28bb1dd81360850@haskell.org> References: <049.4776fec4b1507e73e28bb1dd81360850@haskell.org> Message-ID: <064.3a2bca70a0e47f23bbfc980886b0c767@haskell.org> #4284: Adding parentheses introduces type error -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.3 (Type checker) | Keywords: higher-rank Resolution: fixed | polymorphism Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | typecheck/should_compile/T4284 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by asr): * cc: andres.sicard.ramirez@? (removed) * cc: asr (added) * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 15:21:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 15:21:19 -0000 Subject: [GHC] #4489: The new flag -fwarn-missing-import-lists does not recognize the (..) form of import. In-Reply-To: <047.67fcac858f586653b55005e921f3db6b@haskell.org> References: <047.67fcac858f586653b55005e921f3db6b@haskell.org> Message-ID: <062.ea71b210eb382223e987777494d18ced@haskell.org> #4489: The new flag -fwarn-missing-import-lists does not recognize the (..) form of import. -------------------------------------+------------------------------------- Reporter: andressr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.4.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | rename/should_compile/T4489 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by asr): * cc: andres.sicard.ramirez@? (removed) * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 15:21:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 15:21:34 -0000 Subject: [GHC] #9638: Speed up Data.Char.isDigit In-Reply-To: <045.8305c40432408fead5554261d41a3400@haskell.org> References: <045.8305c40432408fead5554261d41a3400@haskell.org> Message-ID: <060.73c02f63ed1704a78817087d2456bfd1@haskell.org> #9638: Speed up Data.Char.isDigit -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): The same should probably apply to the (non-exported) `between` function in `GHC.IO.Encoding.UTF8`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 15:22:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 15:22:28 -0000 Subject: [GHC] #5806: Make TimeLocale an instance of Def In-Reply-To: <048.3635c7c6131955aed34e3c76dc9bf04e@haskell.org> References: <048.3635c7c6131955aed34e3c76dc9bf04e@haskell.org> Message-ID: <063.fd6145c9d629709f4eca17d437a0574d@haskell.org> #5806: Make TimeLocale an instance of Def -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.2.2 Component: libraries | Keywords: /old-time | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by asr): * cc: andres.sicard.ramirez@? (removed) * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 15:23:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 15:23:54 -0000 Subject: [GHC] #4817: Missing new flags description in the user guide In-Reply-To: <047.40ad27a488c2deffb4d712031be5348a@haskell.org> References: <047.40ad27a488c2deffb4d712031be5348a@haskell.org> Message-ID: <062.b1adcff9000e98e557d84b73e4198fcf@haskell.org> #4817: Missing new flags description in the user guide -------------------------------------+------------------------------------- Reporter: andressr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.4.2 Component: | Version: 7.4.1 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 17:33:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 17:33:23 -0000 Subject: [GHC] #9638: Speed up Data.Char.isDigit In-Reply-To: <045.8305c40432408fead5554261d41a3400@haskell.org> References: <045.8305c40432408fead5554261d41a3400@haskell.org> Message-ID: <060.64ae2fb90e8797655507b1314ba17af9@haskell.org> #9638: Speed up Data.Char.isDigit -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: hvr, ekmett (added) * component: Compiler => libraries/base Comment: This approach should also combine well with ways digits are used. For instance, we could write (hopefully with better formatting) {{{#!hs digitToInt :: Char -> Int digitToInt c = case ord c - ord '0' of d | (fromIntegral d::Word) <= 9 -> d | otherwise -> case ord c - ord 'a' of e | (fromIntegral e::Word) <= 5 -> e + 10 | otherwise -> case ord c - ord 'A' of f | (fromIntegral f::Word) <= 5 -> f + 10 | otherwise = error ("Char.digitToInt: not a digit " ++ show c) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 19:07:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 19:07:41 -0000 Subject: [GHC] #1487: unix package: test needed for getLoginName In-Reply-To: <047.1ef8c4d73f5dccee00ba133a94dc0060@haskell.org> References: <047.1ef8c4d73f5dccee00ba133a94dc0060@haskell.org> Message-ID: <062.8682cc2101321bff5660de61e24599c3@haskell.org> #1487: unix package: test needed for getLoginName -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: | Version: libraries/unix | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Easy (less than 1 Type of failure: Incorrect | hour) result at runtime | Blocked By: Test Case: | Related Tickets: #8293 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): A [http://www.haskell.org/pipermail/libraries/2014-September/023798.html library proposal] to solve this. The test has been [https://github.com/haskell/unix/commit/e7ce4a66113a910af6327b3192e9ce4879a453cc disabled] again for the time being. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 19:12:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 19:12:27 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.c75905f0e6d18e9d29758e7c980c756e@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"319703ee0c97c593be514222fdee06555816cda4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="319703ee0c97c593be514222fdee06555816cda4" Don't re-export `Alternative(..)` from Control.Monad (re #9586) This was done in d94de87252d0fe2ae97341d186b03a2fbe136b04 to avoid orphans but since a94dc4c3067c6a0925e2e39f35ef0930771535f1 moved `Alternative` into GHC.Base, this isn't needed anymore. This is important, as otherwise this would require a non-neglectable amount of `Control.Monad hiding ((<|>), empty)` imports in user code. The Haddock submodule is updated as well Test Plan: partial local ./validate --fast, let Harbormaster doublecheck it Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D248 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 19:24:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 19:24:36 -0000 Subject: [GHC] #9638: Speed up Data.Char.isDigit In-Reply-To: <045.8305c40432408fead5554261d41a3400@haskell.org> References: <045.8305c40432408fead5554261d41a3400@haskell.org> Message-ID: <060.87c6ee70506a02c4ed4949c5cccf6cdb@haskell.org> #9638: Speed up Data.Char.isDigit -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): These sound reasonable, do we have any (micro)benchmarks to validate that theres a meaningful improvement in performance to pay down the increased complexity of the implementation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 19:26:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 19:26:32 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.1cfd8981f071f2147467409aa9fa3ecd@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Simon and I chatted about this this morning and we thought that your program is a little suspect, perhaps, but not type-incorrect. After all, `T Bool` is inhabited, by `undefined`. To me, suggesting that `T Bool` is unequivocally an error is somewhat like saying `Void` is an error. On the other hand, writing `T Bool` is probably a mistake. We thought a good solution here would be to report a warning in this case. Specifically, warn whenever a closed type family is called on arguments that are apart from all the family's left-hand sides. Would that be a good solution? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 20:17:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 20:17:26 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.4a8e074048812bfbabddff622a0c1ddc@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by augustss): I don't think a warning is right, I think it's an error. I view closed type families as functions on types, and when you use a function you expect it to reduce to a normal form. With a warning you're saying that T x is sometimes equal to some other type and sometimes it's a new type. That makes no sense to me. It has nothing to do with being inhabited, uninhabited types are perfectly fine. It like saying that if I define a function 'f False = ()' and then do 'print (f True)' it would print "f True", i.e., elevating the function symbol f from a function to a constructor just because it's partial. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 20:18:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 20:18:40 -0000 Subject: [GHC] #9637: Type level programming needs an error function In-Reply-To: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> References: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> Message-ID: <062.c2bc5fefe0db7348f08bdf903a9d9a78@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by augustss): I'll experiment and see what seems to work well in the Mu compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 20:32:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 20:32:58 -0000 Subject: [GHC] #9638: Speed up Data.Char.isDigit In-Reply-To: <045.8305c40432408fead5554261d41a3400@haskell.org> References: <045.8305c40432408fead5554261d41a3400@haskell.org> Message-ID: <060.4697cbb78c233fe1f625ce69fdf3b050@haskell.org> #9638: Speed up Data.Char.isDigit -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 carter]: > These sound reasonable, do we have any (micro)benchmarks to validate that there's a meaningful improvement in performance to pay down the increased complexity of the implementation? Yes. I tested evaluating `nf (map isDigit) testcase` with the following test cases: {{{#!hs toosmall = replicate 700 '-' toobig = replicate 700 'a' justright = replicate 700 '7' arb = "12asaa489oneuhl98'c43rub93d'i'i98car278urnatehodth98228hteou84348hcae84--- - - 424 42 hteohu 2 4hto24hth ehua942dp.dghckbaa---; 48923" arbitrary = arb ++ arb ++ reverse arb ++ reverse arb }}} As expected, the fancy code seemed to be very slightly worse for `toosmall`, certainly not worse enough to really get a proper measurement (it's only one extra addition). The rest did better with the fancy code; the difference was consistently biggest for `arbitrary`. Obviously we're not talking huge changes, but I think this function and similar ones get a good bit of use, so it's probably worth bothering. {{{ benchmarking toosmall/old time 12.31 ?s (12.27 ?s .. 12.36 ?s) 1.000 R? (0.999 R? .. 1.000 R?) mean 12.37 ?s (12.34 ?s .. 12.40 ?s) std dev 100.2 ns (69.41 ns .. 138.7 ns) benchmarking toosmall/new time 12.42 ?s (12.41 ?s .. 12.43 ?s) 1.000 R? (1.000 R? .. 1.000 R?) mean 12.43 ?s (12.42 ?s .. 12.44 ?s) std dev 36.07 ns (24.75 ns .. 59.63 ns) benchmarking toobig/old time 13.05 ?s (13.04 ?s .. 13.06 ?s) 1.000 R? (1.000 R? .. 1.000 R?) mean 13.05 ?s (13.04 ?s .. 13.06 ?s) std dev 26.99 ns (19.95 ns .. 43.44 ns) benchmarking toobig/new time 12.43 ?s (12.42 ?s .. 12.45 ?s) 1.000 R? (1.000 R? .. 1.000 R?) mean 12.45 ?s (12.44 ?s .. 12.48 ?s) std dev 65.84 ns (32.99 ns .. 129.0 ns) benchmarking justright/old time 13.07 ?s (13.06 ?s .. 13.08 ?s) 1.000 R? (1.000 R? .. 1.000 R?) mean 13.08 ?s (13.06 ?s .. 13.09 ?s) std dev 42.63 ns (30.33 ns .. 56.90 ns) benchmarking justright/new time 12.41 ?s (12.40 ?s .. 12.42 ?s) 1.000 R? (1.000 R? .. 1.000 R?) mean 12.41 ?s (12.41 ?s .. 12.42 ?s) std dev 25.29 ns (21.00 ns .. 31.20 ns) benchmarking arbitrary/old time 11.69 ?s (11.68 ?s .. 11.71 ?s) 1.000 R? (1.000 R? .. 1.000 R?) mean 11.69 ?s (11.68 ?s .. 11.71 ?s) std dev 50.41 ns (21.45 ns .. 85.71 ns) benchmarking arbitrary/new time 10.65 ?s (10.64 ?s .. 10.66 ?s) 1.000 R? (1.000 R? .. 1.000 R?) mean 10.65 ?s (10.64 ?s .. 10.66 ?s) std dev 21.31 ns (14.90 ns .. 36.62 ns) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 26 21:43:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Sep 2014 21:43:58 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.9af5378ac6cb10807e8c84ba2061d183@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:2 augustss]: > I don't think a warning is right, I think it's an error. I view closed type families as functions on types, and when you use a function you expect it to reduce to a normal form. With a warning you're saying that T x is sometimes equal to some other type and sometimes it's a new type. That makes no sense to me. It has nothing to do with being inhabited, uninhabited types are perfectly fine. This is not a realm I know anything about, but I agree. `T Bool` is not an uninhabited type?it's simply not a type. The situation for data families is qualitatively different, and it would probably make sense to offer such a warning for those. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 06:35:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 06:35:37 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.023fac8dec46e757d95495aca65dc51a@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by refold): Replying to [comment:8 dfeuer]: > However, the above `dropWhileEndLE` appears to be faster than the double reverse in all cases. So I'll add it to the utilities module and use that instead. Since `dropWhileEndLE` is both faster and has less surprising semantics (spine-strict instead of element-strict), I think that the standard library should be changed to use this version. And we should also add `takeWhileEnd` while we're at it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 07:15:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 07:15:51 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.e140d04ae9fd3b8464e9cecc7aec8c6e@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:9 refold]: > Replying to [comment:8 dfeuer]: > > However, the above `dropWhileEndLE` appears to be faster than the double reverse in all cases. So I'll add it to the utilities module and use that instead. > > Since `dropWhileEndLE` is both faster and has less surprising semantics (spine-strict instead of element-strict), I think that the standard library should be changed to use this version. And we should also add `takeWhileEnd` while we're at it. It seems to be faster in the common case of trimming spaces from fairly short strings. It would be pretty bad for cutting a little bit off the end of a lazily-read file. I would be in favor of adding `dropWhileEndLE` (by some name) to `Data.List`, and perhaps deprecating the name `dropWhileEnd` in favor of something less confusing like `takeUntilLast = dropWhileEnd . not`, but just changing the semantics of an existing function seems generally frowned upon. That said, the semantics of `Data.Text.Lazy.dropWhileEnd`, that someone suggested I check into, are much more confusing to me so far, so there may be a bit of room to wiggle things around. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 07:55:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 07:55:23 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.84859a2d7e2460c1ff4ceef2fa0b9ef8@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by refold): Replying to [comment:10 dfeuer]: > It seems to be faster in the common case of trimming spaces from fairly short strings. It would be pretty bad for cutting a little bit off the end of a lazily-read file. Hmm, I see now. That's because {{{ dropWhileEnd isSpace ("foo\n" ++ undefined) == "foo" ++ undefined }}} but {{{ dropWhileEndLE isSpace ("foo\n" ++ undefined) == undefined }}} so the `LE` version would need to read the whole file in memory. IMO the `LE` version is more practical since you usually do stuff like `return . map (dropWhileEnd isSpace) . lines =<< readFile "foo"` instead of just dropping the end of the file. For reference: the original discussion on the libraries list is [http://www.haskell.org/pipermail/libraries/2011-September/016829.html here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 08:15:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 08:15:02 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.19038327f249a0a0778d005419f6e0dc@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:11 refold]: > Replying to [comment:10 dfeuer]: > > It seems to be faster in the common case of trimming spaces from fairly short strings. It would be pretty bad for cutting a little bit off the end of a lazily-read file. > > Hmm, I see now. That's because > > {{{ > dropWhileEnd isSpace ("foo\n" ++ undefined) == "foo" ++ undefined > }}} > > but > > {{{ > dropWhileEndLE isSpace ("foo\n" ++ undefined) == undefined > }}} > > so the `LE` version would need to read the whole file in memory. > > IMO the `LE` version is more practical since you usually do stuff like `return . map (dropWhileEnd isSpace) . lines =<< readFile "foo"` instead of just dropping the end of the file. > > For reference: the original discussion on the libraries list is [http://www.haskell.org/pipermail/libraries/2011-September/016829.html here]. I see now that Roman Leshchinskiy [http://www.haskell.org/pipermail/libraries/2011-September/016841.html proposed] precisely the definition of what I call `dropWhileEndLE`. It looks like there was a lot of confusion back then about the exact laziness properties of the different proposed definitions, and it appears no one recognized the significance of the order of `&&` operands to the semantics. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 08:43:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 08:43:00 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.abe4734ab5e871bf2e8bc08c0673624d@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): I don't see why `T Bool` is "not a type". If you really want something like that, you should index `T` over a closed kind: {{{ {-# LANGUAGE DataKinds, TypeFamilies #-} data Un = TInt type family T (a :: Un) :: * where T TInt = () }}} Now it's clear that `T Bool` is indeed not a type, and gives rise to a kind error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 08:48:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 08:48:51 -0000 Subject: [GHC] #9639: Remove OldTypeable Message-ID: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I think it's safe to remove `Data.OldTypeable` now. It's been deprecated in 7.8, and we said that we'd remove it for 7.10. This ticket is to record that task, and to check that there are no objections to removing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 09:34:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 09:34:29 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.bd67e61d273122daa436214b6bc6b0e4@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mlen): During HacBerlin I discussed about the issue with Andres and he suggested an alternative approach: instead of detabbing or suppressing the warnings per file, a global suppression flag should be added. It turned out to be very simple to implement. The change can be found here: https://github.com/mlen/ghc/compare/warn-tabs I also continued the detabbing and the patch got very big (https://github.com/mlen/ghc/compare/detabbed), so there may cause trouble when merging. It still doesn't cover all tests (some of them are not run on my machine) and doesn't contain patches for submodules. Is there any reason why the code from https://github.com/mlen/ghc/compare /warn-tabs branch shouldn't be used instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 10:24:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 10:24:54 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.a47d55301e6eaebf8e7f0c0c03903274@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by augustss): To me it's clear that `T Bool` is not a type. To me `T` is a type function which computes a type given a type. But it's a partial function, so only some arguments make sense. New types are created by `data` and `newtype`, not by `type` or `type family`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 10:55:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 10:55:07 -0000 Subject: [GHC] #4879: Deprecate exports In-Reply-To: <049.ea1fa273b308c2a35269907288b50645@haskell.org> References: <049.ea1fa273b308c2a35269907288b50645@haskell.org> Message-ID: <064.3f4d9f6294bc9d3e3a60dd068bad5d81@haskell.org> #4879: Deprecate exports -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.0.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: ekmett (added) Comment: With all the class generalisation work going on in `base`, this may be desirable to have for GHC 7.10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 11:08:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 11:08:55 -0000 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <051.fdfe73ce3bd8dfdeb8a04e3a7bade7ab@haskell.org> References: <051.fdfe73ce3bd8dfdeb8a04e3a7bade7ab@haskell.org> Message-ID: <066.3d3519eb7556a45c857680fc95aa5d6f@haskell.org> #1405: Make ghc (stage1) be compilable by non-GHC -------------------------------------+------------------------------------- Reporter: Isaac | Owner: Dupree | Status: new Type: task | Milestone: ? Priority: normal | Version: 6.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): In [changeset:"206b4dec78250efef3cd927d64dc6cbc54a16c3d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="206b4dec78250efef3cd927d64dc6cbc54a16c3d" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 13:21:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 13:21:19 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs In-Reply-To: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> References: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> Message-ID: <066.478c938c67bddcdae18da3c1a971cd7a@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: patch Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: InstanceSigs (Type checker) | TypeFamilies Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by andreas.abel): Agreed on the horror of the hack! I implemented your suggestion to change the interface of `tcSubType`, see: https://github.com/andreasabel/ghc/commit/e43d6f1f90f8d395fb21696c5f8a1641a75067b5 Instead of `CtOrigin`, it takes a `SwapFlag`. Note that it has to pass an `origin` to `deeplyInstantiate`, and as the original origin is no more communicated to tcSubType, it uses a standard `TypeEqOrigin` now. Whether this has any negative impact is yours to judge... {{{#!hs tcSubType :: SwapFlag -> UserTypeCtxt -> TcSigmaType -> TcSigmaType -> TcM HsWrapper -- Check that ty_actual is more polymorphic than ty_expected -- Both arguments might be polytypes, so we must instantiate and skolemise -- Returns a wrapper of shape ty_actual ~ ty_expected tcSubType swap ctxt ty_actual ty_expected | isSigmaTy ty_actual = do { (sk_wrap, inst_wrap) <- tcGen ctxt ty_expected $ \ _ sk_rho -> do { (in_wrap, in_rho) <- deeplyInstantiate i_origin ty_actual ; cow <- unify in_rho sk_rho ; return (coToHsWrapper cow <.> in_wrap) } ; return (sk_wrap <.> inst_wrap) } | otherwise -- Urgh! It seems deeply weird to have equality -- when actual is not a polytype, and it makes a big -- difference e.g. tcfail104 = do { cow <- unify ty_actual ty_expected ; return (coToHsWrapper cow) } where -- E.g., in the case of patterns and instance signatures, -- we call tcSubType with (expected, actual) -- rather than (actual, expected). To get error messages the -- right way round we create the appropriate origin. unify ty1 ty2 = uType (origin ty1 ty2) ty1 ty2 origin ty1 ty2 = if isSwapped swap then TypeEqOrigin { uo_actual = ty2, uo_expected = ty1 } else TypeEqOrigin { uo_actual = ty1, uo_expected = ty2 } i_origin = origin ty_actual ty_expected }}} Being fine with the reported type errors, we still have a problem for the successful test. {{{#!hs {-# LANGUAGE InstanceSigs, TypeFamilies #-} class C a where type T a m :: T a instance C Int where type T Int = String -- The following type signature for m should be valid. m :: String m = "bla" main :: IO () main = return () }}} Running the test suite `Core Lint` complains about a type mismatch: {{{ *** Core Lint errors : in result of Desugar (after optimization) *** {-# LINE 15 "T9582.hs #-}: Warning: [RHS of $cm_amh :: Main.T GHC.Types.Int] The type of this binder doesn't match the type of its RHS: $cm_amh Binder's type: Main.T GHC.Types.Int Rhs type: [GHC.Types.Char] *** Offending Program *** $cm_amh :: Main.T GHC.Types.Int [LclId, Str=DmdType] $cm_amh = GHC.CString.unpackCString# "bla"# Main.$fCInt [InlPrag=INLINE (sat-args=0)] :: Main.C GHC.Types.Int [LclIdX[DFunId(nt)], Str=DmdType, Unf=Unf{Src=InlineStable, TopLvl=True, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=False,boring_ok=True) Tmpl= $cm_amh `cast` (Sym (Main.NTCo:C[0] _N) :: Main.T GHC.Types.Int ~R# Main.C GHC.Types.Int)}] Main.$fCInt = $cm_amh `cast` (Sym (Main.NTCo:C[0] _N) :: Main.T GHC.Types.Int ~R# Main.C GHC.Types.Int) ... *** End of Offense *** }}} Sounds like we cannot throw away the cast after all!? [The type synonym T Int = String does not seem to make it down to this level!?] We could return a cast from `check_inst_sig`. However, `TcSigInfo` which is produced by `mkMethIds`, does not provide for the storage of a coercion... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 18:58:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 18:58:40 -0000 Subject: [GHC] #7987: GHC Build Error In-Reply-To: <049.13a5670aea2715ca1b071014ac4c95b6@haskell.org> References: <049.13a5670aea2715ca1b071014ac4c95b6@haskell.org> Message-ID: <064.387d078d362e8a536043da448fcbcac5@haskell.org> #7987: GHC Build Error ----------------------------------------------+--------------------------- Reporter: singpolyma | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by singpolyma): * status: infoneeded => closed * resolution: => invalid Comment: Not sure if it's still present, and I worked around it for what I was doing at the time, so this can be closed, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 19:09:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 19:09:54 -0000 Subject: [GHC] #7987: GHC Build Error In-Reply-To: <049.13a5670aea2715ca1b071014ac4c95b6@haskell.org> References: <049.13a5670aea2715ca1b071014ac4c95b6@haskell.org> Message-ID: <064.cd6e5d8c6c7644d1dfdc3fedaad67836@haskell.org> #7987: GHC Build Error ----------------------------------------------+--------------------------- Reporter: singpolyma | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by rwbarton): I think this actually is fixed by 5fb72555f7b7ab67a33583f33ad9160761ca434f which I happened to come across today for unrelated reasons. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 20:58:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 20:58:35 -0000 Subject: [GHC] #8842: Make sure msys2 builds non emulating binaries In-Reply-To: <046.86a6364bab91651953306fe81692398f@haskell.org> References: <046.86a6364bab91651953306fe81692398f@haskell.org> Message-ID: <061.ed822fdcd397b708e74d534345fb555b@haskell.org> #8842: Make sure msys2 builds non emulating binaries -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.1-rc2 System | Keywords: msys2 Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * cc: gintas (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 21:52:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 21:52:15 -0000 Subject: [GHC] #9326: Minor change to list comprehension structure leads to poor performance In-Reply-To: <045.1c317aaff8c19da25888a5984a88d8bc@haskell.org> References: <045.1c317aaff8c19da25888a5984a88d8bc@haskell.org> Message-ID: <060.b7354788be9f461e44f5facce9239c0e@haskell.org> #9326: Minor change to list comprehension structure leads to poor performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => invalid Comment: It looks like the original reporter was able to resolve the problem by adding some type signatures to get things specialized earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 21:53:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 21:53:54 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.ff60c9a78b507acc5bff2706ad9b39cf@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => wontfix Comment: It seems clear this is too controversial, at least for now, so I'll clear it off the table. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 21:56:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 21:56:15 -0000 Subject: [GHC] #9618: Undocument ImpredicativeTypes In-Reply-To: <045.05901419138923a568c2731a51d0dcf7@haskell.org> References: <045.05901419138923a568c2731a51d0dcf7@haskell.org> Message-ID: <060.07076862e82dfaf7b59d7286e6a1852c@haskell.org> #9618: Undocument ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * failure: None/Unknown => Documentation bug * milestone: => 7.10.1 Old description: > I understand that Simon Peyton Jones intends to make `ImpredicativeTypes` > work some day, but it doesn't work now. I think the thing to do for now > is to remove it from the user manual. It can be put back in later if it's > ever fixed. New description: I understand that Simon Peyton Jones intends to make `ImpredicativeTypes` work some day, but it doesn't work now. I think the thing to do for now is to remove it from the user manual. It can be put back in later if and when it's fixed. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 21:58:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 21:58:44 -0000 Subject: [GHC] #9191: Semi-exported names In-Reply-To: <045.d5439bf8b076b8ab603179ac5dbb9835@haskell.org> References: <045.d5439bf8b076b8ab603179ac5dbb9835@haskell.org> Message-ID: <060.b221a945253c7fe1278e0eed99052a4a@haskell.org> #9191: Semi-exported names -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: closed request | Milestone: Priority: low | Version: 7.8.2 Component: Compiler | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => invalid Comment: As this has generated no interest from anyone but me, I'll close it out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 27 22:33:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Sep 2014 22:33:37 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.8f65bd226d003ab41ec022820bc2fedc@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I do not understand the theory here?what is the (not-yet-implemented version of) `isTrue#` supposed to accomplish? If I hand it `12#`, it will dutifully tell me `False`. What exactly have I learned from that? Either I meant for it to return `True` and I just got a wrong answer or I just used a very confusingly-named function to see if something equals `1#`. I could fake C-style booleans if I wanted using `isFalse`, but it would be much clearer to just explicitly compare something to zero. If you wanted to actually get some kind of safety, you'd need something more invasive, with more potential to slow things down, like maybe {{{#!hs isTrue# x | tagToEnum# ((x `orI#` 1#) ==# 1#) = tagToEnum# x | otherwise = error "Oops" }}} I just don't see how the proposed `isTrue#` offers any real advantage over `tagToEnum#`. Using primops is always playing with fire, and something that looks like a safety net but really isn't just invites careless errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 00:32:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 00:32:24 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.10195324c939a98d1169f25e017cd74e@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by amurrayc): Replying to [comment:35 rwbarton]: > Try applying https://phabricator.haskell.org/D208 to HEAD. Doing so fails with {{{ error: out of range pc-relative fixup value vldr d8, LCPI102_0 }}} This is with LLVM 3.4. I'm going to try with LLVM 3.5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 01:48:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 01:48:43 -0000 Subject: [GHC] #9640: Invalid object in processHeapClosureForDead(): 2130762223 Message-ID: <047.4251ac36032806c0b7c6a3cfadb392fc@haskell.org> #9640: Invalid object in processHeapClosureForDead(): 2130762223 -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I just tried using {{{-hb}}} profiling for Yi and hit {{{ yi: internal error: Invalid object in processHeapClosureForDead(): 2130762223 (GHC version 7.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} Unfortunately I don't have an easy way to replicate. In my case it's to check out HEAD version of Yi, build with profiling and run {{{ [nix-shell:~/programming/yi/yi]$ TERM=xterm yi_datadir=. dist/build/yi/yi -fpango --as=emacs -y /tmp /tmp/long +RTS -p -hb }}} where {{{/tmp/long}}} here is just a file with 1MB of the letter {{{A}}} repeated on a single line. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 01:54:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 01:54:10 -0000 Subject: [GHC] #9641: Point-free do block gives missing instance error Message-ID: <045.b58191fc2eb79b10ef8b6b0eaad9fbbf@haskell.org> #9641: Point-free do block gives missing instance error -------------------------------------+------------------------------------- Reporter: rasfar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.1 Keywords: plugins | Operating System: Linux HasDynFlags | Type of failure: Architecture: x86 | Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- https://www.haskell.org/ghc/docs/latest/html/users_guide/compiler- plugins.html#manipulating-bindings This API example won't compile for me. {{{#!hs module SayNames.Plugin (plugin) where import GhcPlugins plugin :: Plugin plugin = defaultPlugin { installCoreToDos = install } install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo] install _ todo = do reinitializeGlobals return (CoreDoPluginPass "Say name" pass : todo) pass :: ModGuts -> CoreM ModGuts pass = do dflags <- getDynFlags bindsOnlyPass (mapM (printBind dflags)) where printBind :: DynFlags -> CoreBind -> CoreM CoreBind printBind dflags bndr@(NonRec b _) = do putMsgS $ "Non-recursive binding named " ++ showSDoc dflags (ppr b) return bndr printBind _ bndr = return bndr }}} Compiling (GHC 7.8.1, or 7.6.3). I get: {{{ SayNames/Plugin.hs:25:21: No instance for (HasDynFlags ((->) ModGuts)) arising from a use of ?getDynFlags? In a stmt of a 'do' block: dflags <- getDynFlags In the expression: do { dflags <- getDynFlags; bindsOnlyPass (mapM (printBind dflags)) } In an equation for ?pass?: pass = do { dflags <- getDynFlags; bindsOnlyPass (mapM (printBind dflags)) } where printBind :: DynFlags -> CoreBind -> CoreM CoreBind printBind dflags bndr@(NonRec b _) = do { putMsgS $ "Non-recursive binding named " ++ showSDoc dflags (ppr b); .... } printBind _ bndr = return bndr }}} Changing to pointful style it compiles and works: {{{#!hs pass modguts = do dflags <- getDynFlags bindsOnlyPass (mapM (printBind dflags)) modguts }}} Maybe this is a compiler bug, actually? Dunno, I never use point-free style with monadic functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 02:15:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 02:15:31 -0000 Subject: [GHC] #9641: Point-free do block gives missing instance error In-Reply-To: <045.b58191fc2eb79b10ef8b6b0eaad9fbbf@haskell.org> References: <045.b58191fc2eb79b10ef8b6b0eaad9fbbf@haskell.org> Message-ID: <060.7401d1e3455fc359b082dfd20af5c663@haskell.org> #9641: Point-free do block gives missing instance error -------------------------------------+------------------------------------- Reporter: rasfar | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.1 Documentation | Keywords: plugins Resolution: | HasDynFlags Operating System: Linux | Architecture: x86 Type of failure: | Difficulty: Unknown Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => rwbarton Comment: Thanks for the report. Yes, it is a documentation bug, just a mixup when the example was updated for 7.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 02:48:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 02:48:25 -0000 Subject: [GHC] #7682: Plugin example not updated for ghc 7.6 In-Reply-To: <044.eb018053bd2a58fe991b8c37e159ef4b@haskell.org> References: <044.eb018053bd2a58fe991b8c37e159ef4b@haskell.org> Message-ID: <059.db8f383b1c6f89ed0c5aa0538058f376@haskell.org> #7682: Plugin example not updated for ghc 7.6 -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Reid Barton ): In [changeset:"071167c793489f4071c348223f9591d20dbe11a3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="071167c793489f4071c348223f9591d20dbe11a3" User's Guide: Fix compiler plugin example (#9641, #7682) The previous fix was incorrectly eta-reduced. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 02:48:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 02:48:25 -0000 Subject: [GHC] #9641: Point-free do block gives missing instance error In-Reply-To: <045.b58191fc2eb79b10ef8b6b0eaad9fbbf@haskell.org> References: <045.b58191fc2eb79b10ef8b6b0eaad9fbbf@haskell.org> Message-ID: <060.3656e9a82399e7963e075784f9c28184@haskell.org> #9641: Point-free do block gives missing instance error -------------------------------------+------------------------------------- Reporter: rasfar | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.1 Documentation | Keywords: plugins Resolution: | HasDynFlags Operating System: Linux | Architecture: x86 Type of failure: | Difficulty: Unknown Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"071167c793489f4071c348223f9591d20dbe11a3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="071167c793489f4071c348223f9591d20dbe11a3" User's Guide: Fix compiler plugin example (#9641, #7682) The previous fix was incorrectly eta-reduced. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 02:48:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 02:48:59 -0000 Subject: [GHC] #9641: Point-free do block gives missing instance error In-Reply-To: <045.b58191fc2eb79b10ef8b6b0eaad9fbbf@haskell.org> References: <045.b58191fc2eb79b10ef8b6b0eaad9fbbf@haskell.org> Message-ID: <060.fdb3680af5d63f8ee277ca4d1c1e52b9@haskell.org> #9641: Point-free do block gives missing instance error -------------------------------------+------------------------------------- Reporter: rasfar | Owner: rwbarton Type: bug | Status: closed Priority: normal | Milestone: Component: | Version: 7.8.1 Documentation | Keywords: plugins Resolution: fixed | HasDynFlags Operating System: Linux | Architecture: x86 Type of failure: | Difficulty: Unknown Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 03:05:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 03:05:56 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.7a7b3665fa3fd677ceb0e6c854f9f10e@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): @dfeuer, (my interpretation is) this ticket is articulating how we'd *like* to write isTrue# and noting some of the optimization engineering thats needed to support writing things in the desired high level fashion. Your safety concern is at least in some small part spurious, because some of this optimization/engineering is about how to transform high level type safe code into that branch free form as optimizations in Core, STG and CMM. That is, end users should not have to deal with this tomfoolery ever, but we'd still like to give them branch free code when its safe! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 03:07:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 03:07:04 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.2d83abe1bf697de3e1f1288ff8ea75bd@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): In the mean time, things like `isTrue#` are not meant to be safe wrapped things, but tools that make performance engineering manageable and tractable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 03:09:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 03:09:10 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.0278683b8a816b5358f6d4343ec65ae2@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): more concretely, that change in definition has impact on other pieces of code generation that needs to be fixed in order have that nicer / safer definition to work out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 03:21:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 03:21:20 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.f220c59a237efba2cb398bc87a86891b@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------------+--------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 Differential Revisions: | ---------------------------------------+--------------------------- Comment (by oerjan): I suspect I just hit this bug when trying to `cabal install random-extras` from Haskell Platform 2014.2.0.0 on Windows 8.1. The dependency `random- fu` uses the `logfloat` library from Template Haskell while compiling other modules, which gives me the error message: {{{ [ 7 of 29] Compiling Data.Random.Distribution.Uniform ( src\Data\Random\Distribu tion\Uniform.hs, dist\build\Data\Random\Distribution\Uniform.o ) Loading package ghc-prim ... linking ... done. [snipped long package list] Loading package logfloat-0.12.1 ... ghc.exe: m: Den angitte modulen ble ikke fun net. : can't load .so/.DLL for: m.dll (addDLL: could not load DLL) Failed to install random-fu-0.2.6.1 cabal: Error: some packages failed to install: random-extras-0.19 depends on random-fu-0.2.6.1 which failed to install. random-fu-0.2.6.1 failed during the building phase. The exception was: ExitFailure 1 }}} `logfloat.cabal` contains precisely such an `Extra-Libraries: m` line that is used in its default configuration. And trying to use `logfloat` from (Win)GHCi gives the same kind of error message. I am able to get around this for `logfloat` by giving `--flags -useFFI`, but I still think it's a shame if this bug prevents a straightforward cabal install from working. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 03:22:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 03:22:09 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.c89a4e97f8578b8de15c316a116c559c@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------------+--------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 Differential Revisions: | ---------------------------------------+--------------------------- Changes (by oerjan): * cc: oerjan@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 03:28:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 03:28:36 -0000 Subject: [GHC] #9641: Point-free do block gives missing instance error In-Reply-To: <045.b58191fc2eb79b10ef8b6b0eaad9fbbf@haskell.org> References: <045.b58191fc2eb79b10ef8b6b0eaad9fbbf@haskell.org> Message-ID: <060.23679075197f42db705766698266513f@haskell.org> #9641: Point-free do block gives missing instance error -------------------------------------+------------------------------------- Reporter: rasfar | Owner: rwbarton Type: bug | Status: closed Priority: normal | Milestone: Component: | Version: 7.8.1 Documentation | Keywords: plugins Resolution: fixed | HasDynFlags Operating System: Linux | Architecture: x86 Type of failure: | Difficulty: Unknown Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rasfar): I can't determine whether it's against etiquette to comment "Thanks!" here after it's closed, but since I already did, thanks... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 06:53:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 06:53:31 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.5638bef023b4fb9a9de855217de74be7@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"a07ce1654ac5b8033f2daf9270c6e182415b69ca/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a07ce1654ac5b8033f2daf9270c6e182415b69ca" Generalise `Control.Monad.{when,unless,guard}` Generalise `when`/`unless`from `Monad` to `Applicative` and `guard` from `MonadPlus` to `Alternative` respectively. This was made possible by the AMP and is somewhat related to #9586 (but generalising in the context of the AMP instead of the FTP) Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D253 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 07:22:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 07:22:00 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.8f40152c4330cbc17aac0edffb16544a@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > More details to follow. I've created this ticket to be able to refer to > from related preparatory commits. > > In a nutshell the goal (more or less) of this proposal is to be able to > compile code like the following w/o errors (due to conflicting > definitions): > > {{{#!hs > module XPrelude (module X) where > > import Data.Foldable as X > import Data.Traversable as X > import Data.List as X > import Control.Monad as X > import Prelude as X > }}} New description: More details to follow. I've created this ticket to be able to refer to from related preparatory commits. In a nutshell the FTP (Foldable/Traversable-Proposal) sub-goal of the BBP (Burning-Bridges-Proposal) includes to be able to compile code like the following w/o errors (due to conflicting definitions): {{{#!hs module XPrelude (module X) where import Data.Foldable as X import Data.Traversable as X import Data.List as X import Control.Monad as X import Prelude as X }}} Other goals include to generalise/weaken type-signatures where possible w/o breaking (much) compatibility with existing code. An in-depth design- document is in the works. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 07:55:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 07:55:46 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.1f2602170bc49526739959574b92c17b@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:3 dfeuer]: > If I hand it `12#`, it will dutifully tell me `False`. What exactly have I learned from that? That the argument you passed is not a valid tag for `True`. This ticket is not really about `isTrue#` or `isFalse#` - which are just tools a programmer might want or not want to use - but about fixing the heap checks and thus fixing #8317. If you feel that `isTrue#` and `isFalse#` don't offer you any benefit you can still use `tagToEnum#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 08:12:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 08:12:39 -0000 Subject: [GHC] #9526: Add missing Generic instances in base In-Reply-To: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> References: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> Message-ID: <057.51abf0036de9fcdc3467defcfcb4ebcc@haskell.org> #9526: Add missing Generic instances in base -------------------------------------+------------------------------------- Reporter: nh2 | Owner: dreixel Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 9527 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): Actually, I'm thinking that perhaps we should delete the existing `Generic` instances for base types. They don't really add much; the only thing I can think of is that you can find out the module and datatype name. Other than that, any generic function will still have to provide adhoc behaviour for types such as `Int`, because there is no generic behaviour for these base types. Also, this doesn't really block #9527, as far as I can see. You can derive `Generic` for a datatype that contains `Integer`, for example, which doesn't have a `Generic` instance. Things only fail when you try to use a generic function that does not have an instance for `Integer`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 09:44:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 09:44:32 -0000 Subject: [GHC] #8751: Show parenthesised output of expressions in ghci In-Reply-To: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> References: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> Message-ID: <066.e40c081aae488407042da7ba3c294647@haskell.org> #8751: Show parenthesised output of expressions in ghci -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: patch Type: feature | Milestone: 7.10.1 request | Version: 7.6.3 Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: infoneeded => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 10:49:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 10:49:10 -0000 Subject: [GHC] #9642: LANGUAGE pragma synonyms Message-ID: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> #9642: LANGUAGE pragma synonyms -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Here are the first 20 lines of a typical Haskell file of mine: {{{ {-# LANGUAGE EmptyDataDecls #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE LiberalTypeSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE AutoDeriveTypeable #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE OverlappingInstances #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ConstraintKinds #-} }}} Over a couple of modules in a small package, I find myself copy-pasting these 20 lines, as either I will use these extensions, or they won't really cause any harm to the code I'm writing. As a way to simplify this, and reduce code duplication, I propose introducing LANGUAGE pragma synonyms: {{{ {-# LANGUAGE PedrosHaskell = EmptyDataDecls, FlexibleContexts, FlexibleInstances , LiberalTypeSynonyms, ScopedTypeVariables , RankNTypes, StandaloneDeriving, AutoDeriveTypeable , DeriveDataTypeable, DeriveGeneric, DefaultSignatures , OverlappingInstances, UndecidableInstances , MultiParamTypeClasses, TypeOperators, TypeFamilies , GADTs, DataKinds, PolyKinds, ConstraintKinds #-} }}} After writing this, in that same module or any module that imports it, I could just write: {{{ {-# LANGUAGE PedrosHaskell #-} }}} And all the pragmas above would be enabled. Besides making my life easier, I suspect this will also help increase modularity of certain packages. For example, packages could define a package-specific language pragma that should be enabled in order to use that package. Then, if the package maintainer upgrades one datatype to become a GADT, the pragma would be updated to include `GADTs`, and user code (that could now be requiring that pragma) would automatically enable `GADTs` too. Furthermore, it can also make the language standardisation process simpler. After all, {{{ {-# LANGUAGE Haskell2010 = PatternGuards, NoNPlusKPatterns, RelaxedPolyRec , EmptyDataDecls, ForeignFunctionInterface #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 11:29:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 11:29:26 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.125f54ba093297dbbbabdd86c0dce0a4@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: highest | Version: 6.12.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7880 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D211 | -------------------------------------+------------------------------------- Comment (by monoidal): I think we can make an exception and remove the warning flag in 7.12. There's no point in explicitly specifying it, and if someone needs to use `-fno-warn-context-quantification`, his code will break in 7.12 anyway. Richard: When I was implementing this almost a year ago, I downloaded the entire hackage archive and did {{{ grep -r "type.*=.* =>" --include=*s | grep -v "forall" }}} and manually filtered out correct uses. This found 46 errors in 26 packages. This number is an underestimation, since it does not count "data", multiline definitions or other situations affected by the change (TH type quotations or signatures such as `forall b. b -> (Ord a => a)`). Based on this, I decided to make it a warning first. I can investigate further if needed. Simon: We cannot use `Explicit` instead of `Qualified` because `Explicit` has precedence over `Implicit`, and valid code such as `f :: Ord a => a -> b -> a; f = const` would break. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 12:42:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 12:42:05 -0000 Subject: [GHC] #9642: LANGUAGE pragma synonyms In-Reply-To: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> References: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> Message-ID: <061.189fb4524fe1057439eb21f98e44ab7f@haskell.org> #9642: LANGUAGE pragma synonyms -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Are you aware of the possibility of specifying extensions in package's `.cabal` file? Here's an example: {{{ library hs-source-dirs: src exposed-modules: ... build-depends: ... extensions: BangPatterns EmptyDataDecls FlexibleContexts FlexibleInstances ... }}} This addresses the issue of code duplication. It does not address auto- enabling of LANGUAGE extensions for modules that import a package. Personally I don't like the idea of having extensions automatically (and implicitly) enabled without my knowledge just because I imported a module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 12:50:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 12:50:28 -0000 Subject: [GHC] #9642: LANGUAGE pragma synonyms In-Reply-To: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> References: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> Message-ID: <061.2f82bb598d7f739666530988b14d0941@haskell.org> #9642: LANGUAGE pragma synonyms -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): Replying to [comment:1 jstolarek]: > Are you aware of the possibility of specifying extensions in package's `.cabal` file? Yes, but I don't think that addresses the same issues that my proposal does. Replying to [comment:1 jstolarek]: > Personally I don't like the idea of having extensions automatically (and implicitly) enabled without my knowledge just because I imported a module. It wouldn't be automatically enabled. It would just be available for use; you'd still have to write {{{ {-# LANGUAGE PedrosHaskell #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 13:07:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 13:07:36 -0000 Subject: [GHC] #9621: New Data.Foldable methods In-Reply-To: <042.d9d7ae0716ad2c4184a4d3189309853b@haskell.org> References: <042.d9d7ae0716ad2c4184a4d3189309853b@haskell.org> Message-ID: <057.ae449eb6eaf93b3165e38a5b20cb815a@haskell.org> #9621: New Data.Foldable methods -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9586 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"e5cca4ab246ca2d1ecdd7c39eefd3157547cb6aa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e5cca4ab246ca2d1ecdd7c39eefd3157547cb6aa" Extend `Foldable` class with `length` and `null` methods This completes the `Foldable` class by two important operations which this way can be optimised for the underlying structure more easily. A minor fix for the `containers` submodule was needed to due name clash Addresses #9621 Reviewed By: ekmett, dfeuer, austin Differential Revision: https://phabricator.haskell.org/D250 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 13:15:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 13:15:50 -0000 Subject: [GHC] #9642: LANGUAGE pragma synonyms In-Reply-To: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> References: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> Message-ID: <061.6a74a6564b44250765596b303a778b7a@haskell.org> #9642: LANGUAGE pragma synonyms -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:2 dreixel]: > Yes, but I don't think that addresses the same issues that my proposal does. Well, it address only one of them (avoiding copy-pastes). > It wouldn't be automatically enabled. It would just be available for use; you'd still have to write > {{{ > {-# LANGUAGE PedrosHaskell #-} > }}} I see. But wouldn't your proposal impose artificial dependencies between modules, where one module needs to import another just to use the LANGUAGE synonym? I imagine this could become a problem in some circumstances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 15:51:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 15:51:41 -0000 Subject: [GHC] #8396: cleanup / refactor native code gens In-Reply-To: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> References: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> Message-ID: <060.c98797301644ecd27407d9f5c8a10777@haskell.org> #8396: cleanup / refactor native code gens -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: Component: Compiler | Keywords: (CodeGen) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #8299 , #8287 Type of failure: | ,#8272 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * component: Compiler => Compiler (CodeGen) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 16:03:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 16:03:31 -0000 Subject: [GHC] #8115: GHC 64-bit Windows build failures with LLVM In-Reply-To: <046.85b4ba291c9a7177535aee44db08c94a@haskell.org> References: <046.85b4ba291c9a7177535aee44db08c94a@haskell.org> Message-ID: <061.c104aaff27f500538870b7c231a2c32f@haskell.org> #8115: GHC 64-bit Windows build failures with LLVM -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: closed Priority: highest | Milestone: ? Component: Compiler | Version: 7.6.3 (LLVM) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * component: Compiler => Compiler (LLVM) * milestone: 7.10.1 => ? Comment: Closing at awson's suggestion. Should be fixed in 7.8.3, please reopen if it is not. A fix for #7143 will be available in the next release, #8974 is still unsolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 16:05:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 16:05:02 -0000 Subject: [GHC] #9643: ghci must be restarted to use break point more than once? Message-ID: <047.e2345eb95a11ab858ce23f47024eee0d@haskell.org> #9643: ghci must be restarted to use break point more than once? -------------------------------------+------------------------------------- Reporter: dsamperi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I set a break point (in main say) I stop there when I run the function, but if I run the function again the break point is ignored. Restarting ghci and resetting the break point makes it effective again, but this seems strange. Is this a bug or a feature? Also, when I run :trace after stopping at a break point, the remainder of the function is run, and :back complains that I cannot go backwards because I am not at a break point. Thanks, Dominick -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 16:10:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 16:10:42 -0000 Subject: [GHC] #9584: Interface file errors (Iface type variable out of scope: k) In-Reply-To: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> References: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> Message-ID: <065.caf08537bf2e5c893e29a10980a2f9dc@haskell.org> #9584: Interface file errors (Iface type variable out of scope: k) -------------------------------------+------------------------------------- Reporter: | Owner: jonsterling | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9263 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by AlexanderThiemann): I get this error when trying to run my test-suite: {{{ ? cabal test ./Spock.cabal has been changed. Re-configuring with most recently used options. If this fails, please run configure manually. Resolving dependencies... Configuring Spock-0.7.0.0... Building Spock-0.7.0.0... Preprocessing library Spock-0.7.0.0... [12 of 13] Compiling Web.Spock.Internal.TextRouting ( src/Web/Spock/Internal/TextRouting.hs, dist/build/Web/Spock/Internal/TextRouting.o ) [13 of 13] Compiling Web.Spock.Simple ( src/Web/Spock/Simple.hs, dist/build/Web/Spock/Simple.o ) In-place registering Spock-0.7.0.0... Preprocessing test suite 'spocktests' for Spock-0.7.0.0... [2 of 4] Compiling Web.Spock.SimpleSpec ( test/Web/Spock/SimpleSpec.hs, dist/build/spocktests/spocktests-tmp/Web/Spock/SimpleSpec.o ) /Users/athiemann/devel/Spock/dist/build/Web/Spock/Internal/TextRouting.hi Declaration for textRegistry1: Iface type variable out of scope: k Cannot continue after interface file error }}} I think I am stumbling over the issue on both GHC7.6 and GHC7.8. I'm not sure how I can create a smaller test case, so I'll just point you to the commit and the travis build: https://github.com/agrafix/Spock/tree/575fdb1332b719a23d84e1fbb67f097f22d64e68 https://travis-ci.org/agrafix/Spock/builds/36477042 cabal clean "solves" the issue... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 16:44:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 16:44:58 -0000 Subject: [GHC] #781: GHCi on x86_64, cannot link to static data in shared libs In-Reply-To: <044.a73c522b97030f99c5fa39d521657f06@haskell.org> References: <044.a73c522b97030f99c5fa39d521657f06@haskell.org> Message-ID: <059.0ee77c5b40800cad37bf369d0c40c6a1@haskell.org> #781: GHCi on x86_64, cannot link to static data in shared libs -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 6.5 Resolution: fixed | Keywords: getEnvironment Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: getEnvironment01 | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: I repeated the test from comment 13 on 64 bit Linux. With GHC 7.6.3: {{{ Prelude Main> main -907777 }}} With GHC 7.8.3: {{{ *Main> main 42 }}} The getEnvironment01 test also passes when started with: {{{ make TEST=getEnvironment01 WAYS=ghci test }}} Therefore I conclude this issue can be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 16:47:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 16:47:14 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.feff65bcd67779b35d843e4f64a9937e@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:7 jstolarek]: > Replying to [comment:3 dfeuer]: > > If I hand it `12#`, it will dutifully tell me `False`. What exactly have I learned from that? > That the argument you passed is not a valid tag for `True`. > > This ticket is not really about `isTrue#` or `isFalse#` - which are just tools a programmer might want or not want to use - but about fixing the heap checks and thus fixing #8317. If you feel that `isTrue#` and `isFalse#` don't offer you any benefit you can still use `tagToEnum#`. I'm not sure where the appropriate place is for this line of discussion, but it seems that in the wild (all over the library source), `isTrue#` is typically used as a function for converting from `Int#`, produced by a comparison operator, to `Bool`, rather than as a validity test for `True`. I have yet to see any explanation of why that is appropriate. Certainly, optimizing heap checks is an entirely different matter, and presumably a good idea regardless. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 17:26:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 17:26:24 -0000 Subject: [GHC] #9644: mapMaybes documentation contains some gibberish Message-ID: <044.8b0e339ed9c82d4dd97bbc57d2bf1135@haskell.org> #9644: mapMaybes documentation contains some gibberish -------------------------------------+------------------------------------- Reporter: mineo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Other hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- "If it just Just b, [...]" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 18:11:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 18:11:28 -0000 Subject: [GHC] #9644: mapMaybes documentation contains some gibberish In-Reply-To: <044.8b0e339ed9c82d4dd97bbc57d2bf1135@haskell.org> References: <044.8b0e339ed9c82d4dd97bbc57d2bf1135@haskell.org> Message-ID: <059.ea0f1e0e6e26563aa2498b0c4772ba61@haskell.org> #9644: mapMaybes documentation contains some gibberish -------------------------------------+------------------------------------- Reporter: mineo | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 18:33:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 18:33:09 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.90422808c4faf368aa3f572537749516@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): I ran some experiments with -A and it does help a lot with performance, but also increases peak memory usage. I observed continuous improvement all the way from -A1m to -A128m in terms of walltime (41s to 36s), but "total memory in use" also went up from 265MB to 2182MB. Not sure where the sweet spot is. -A seems to help especially if the number of capabilities exceeds the number of cores. With 32 capabilities on a 16 core machine, a -qg run took 50s, -A128m took 41s (still a penalty over 36s but not nearly as bad) and a vanilla run took almost 2min. Of course, total memory use with -A128m went up to 4388m... Looks like the sweet spot is somewhere in the middle. How about building ghc --with-rtsopts=-A16m by default? Are there any downsides to that? On my machine the "total memory in use" overhead for that is less than 2x (475MB vs 265MB) and it really helps especially in the degenerate cases. (The machine I was testing on had 16 real cores without any hyperthreading.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 18:34:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 18:34:35 -0000 Subject: [GHC] #9642: LANGUAGE pragma synonyms In-Reply-To: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> References: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> Message-ID: <061.d28c54611333052fc035076e463ffe9a@haskell.org> #9642: LANGUAGE pragma synonyms -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): What about using {{{#!hs {-# LANGUAGE CPP #-} #include "pedros_haskell.inc" }}} ? :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 19:24:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 19:24:37 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.8873703724f64e6b35f5a67d8cd9756d@haskell.org> #5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------- Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 20:49:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 20:49:23 -0000 Subject: [GHC] #3509: libffi.so not found on Mac OS X (10.5.8) In-Reply-To: <046.e078f62d85671282d5ab3883ebdd8e48@haskell.org> References: <046.e078f62d85671282d5ab3883ebdd8e48@haskell.org> Message-ID: <061.7a4775a663d6a0f8f14036b83d7047ea@haskell.org> #3509: libffi.so not found on Mac OS X (10.5.8) -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.10.1 Component: Build | Version: 6.11 System | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: #8266 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: => Building GHC failed * resolution: => duplicate * related: => #8266 Comment: This should long be fixed. See [changeset:"4dd52f2ad3347e604d6a77bac1f8cdd8120dcd03/ghc"]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 21:17:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 21:17:30 -0000 Subject: [GHC] #3470: OSX installer should give an informative error message when XCode is missing In-Reply-To: <053.606cf8b25459ae2fb498c9543397706e@haskell.org> References: <053.606cf8b25459ae2fb498c9543397706e@haskell.org> Message-ID: <068.7d210887b1ebc33c6be7b7a3a7c6ad0b@haskell.org> #3470: OSX installer should give an informative error message when XCode is missing -----------------------------------------+--------------------------- Reporter: GregoryCollins | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.10.1 Component: Build System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: This was fixed in 353c15e16dbb98e5efcdb10558837c4303df9344 (2011). {{{ Os X: With Xcode 4, check for gcc-4.2 also in the setup for binary distributions }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 21:49:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 21:49:20 -0000 Subject: [GHC] #9642: LANGUAGE pragma synonyms In-Reply-To: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> References: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> Message-ID: <061.38cb0369d8ce699a62f8164f940b9d5b@haskell.org> #9642: LANGUAGE pragma synonyms -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): What about introducing an official (GHC-official, not Haskell standard) BleedingEdge pragma (or something like that) that is an amalgamation of most used and bleeding pragmas in GHC? Then if I want to use GHC with all or most features I would only have to add: {{{ #!haskell {-# LANGUAGE BleedingEdge #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 22:20:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 22:20:35 -0000 Subject: [GHC] #3003: Happy does not reject pragmas In-Reply-To: <043.1fd1758c7687447f05a74bae43d4e79c@haskell.org> References: <043.1fd1758c7687447f05a74bae43d4e79c@haskell.org> Message-ID: <058.0b0ba4b769b090b5790e72ee794d1211@haskell.org> #3003: Happy does not reject pragmas -------------------------------------+------------------------------------- Reporter: SamB | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.10.1 Component: Build | Version: 6.10.1 System | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: => None/Unknown * resolution: => invalid Comment: Thank you for your report. This doesn't seem like a GHC problem (anymore). To make sure Happy doesn't treat the pragma as a comment (it doesn't know about pragmas, as you noticed), wrap it in an extra pair of curly braces, so that it is treated as a [http://www.haskell.org/happy/doc/html/sec- grammar-files.html module header]. {{{ {{-# OPTIONS_GHC -fno-warn-missing-signatures #-}} {- -*- Haskell -*- -} %tokentype { Token } %% doc : { } }}} If you're still having problems with happy, please reraise it at the Happy issue tracker: https://github.com/simonmar/happy/issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 28 22:42:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Sep 2014 22:42:22 -0000 Subject: [GHC] #9642: LANGUAGE pragma synonyms In-Reply-To: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> References: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> Message-ID: <061.ae0504a12c9ff9197a0b8545d4088241@haskell.org> #9642: LANGUAGE pragma synonyms -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:5 rodlogic]: > What about introducing an official (GHC-official, not Haskell standard) BleedingEdge pragma (or something like that) that is an amalgamation of most used and bleeding pragmas in GHC? Then if I want to use GHC with all or most features I would only have to add: That sounds a lot like the `-fglasgow-exts` flag that was deprecated a few years ago in favour of specifying individual extensions... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 04:33:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 04:33:07 -0000 Subject: [GHC] #9638: Speed up Data.Char.isDigit In-Reply-To: <045.8305c40432408fead5554261d41a3400@haskell.org> References: <045.8305c40432408fead5554261d41a3400@haskell.org> Message-ID: <060.1cd0c6cbab2434d1b95e70d3599d99da@haskell.org> #9638: Speed up Data.Char.isDigit -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by schyler): +1 from me, cool idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 04:58:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 04:58:05 -0000 Subject: [GHC] #9638: Speed up Data.Char.isDigit In-Reply-To: <045.8305c40432408fead5554261d41a3400@haskell.org> References: <045.8305c40432408fead5554261d41a3400@haskell.org> Message-ID: <060.fd54da24cdb83fa628852c4e5da3a758@haskell.org> #9638: Speed up Data.Char.isDigit -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): Given the benchmarks it looks good to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 07:06:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 07:06:55 -0000 Subject: [GHC] #9645: Optimize range checks for primitive types Message-ID: <045.92f401276495cf27808c2ec9a9d79578@haskell.org> #9645: Optimize range checks for primitive types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This came up in the context of #9638. A special case of Carter's recent suggestion that we try to find ways to automatically use branchless operators in some cases is to optimize the test {{{#!hs a <= x && x <= b }}} when `a` and `b` are statically known, along with minor variations that use strict comparisons. The general pattern is that when `a` and `b` are statically known values that look sufficiently like machine integers (including primitive `Enum` values), `a <= x && x <= b` can be optimized either to `seq x False` (if `b < a`) or to `(fromIntegral (x - a) :: Word) <= (fromIntegral (b - a))` (if `a <= b`). This would almost always be a good thing, because at its worst, `x < a`, it's slower than the original expression by a single addition, but it avoids a potentially expensive conditional jump. Of course, by the time it gets to the point where any such optimizations might take place, everything will have been converted to case expressions nested in some arbitrary fashion; if we're lucky, we'll get something we can recognize, like {{{#!hs case a <= x of True -> case x <= b of True -> e1 False -> e2 False -> e2 }}} or {{{#!hs case x <= b of True -> a <= x False -> False }}} I don't know if we'll always be so lucky, but I think it may make sense to at least try to recognize these and similar forms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 07:11:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 07:11:11 -0000 Subject: [GHC] #9638: Speed up Data.Char.isDigit In-Reply-To: <045.8305c40432408fead5554261d41a3400@haskell.org> References: <045.8305c40432408fead5554261d41a3400@haskell.org> Message-ID: <060.15a2c3e576bbc33cbc821c80976285c3@haskell.org> #9638: Speed up Data.Char.isDigit -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Well, fire up a code-revision over at Phab:differential :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 07:20:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 07:20:36 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.fdbee269d876b15106a1fb8bc14b3a06@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 07:38:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 07:38:03 -0000 Subject: [GHC] #9642: LANGUAGE pragma synonyms In-Reply-To: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> References: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> Message-ID: <061.f7b6e7d41b1e864e1e1956b40b4dde60@haskell.org> #9642: LANGUAGE pragma synonyms -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): I like it. I worry that the implementation is non-trivial: After all, you?d want the parser to know about the pragmas, and you need the parsed module before knowing the import list. How about putting these aliases into the package database? This is loaded before an individual module is loaded and avoids module dependencies? I.e. a new stanza: {{{ language PedrosHaskell extensions: BangPatterns EmptyDataDecls FlexibleContexts FlexibleInstances }}} in some dependencies? `.cabal` file? (This opens the way to other `cabal` flags to be used here, e.g. compiler flags to load a specific plugin, which might be very useful, but let?s not go there with this proposal yet.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 07:46:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 07:46:07 -0000 Subject: [GHC] #9642: LANGUAGE pragma synonyms In-Reply-To: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> References: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> Message-ID: <061.d6c075192d4847e54c93d09de1e08abd@haskell.org> #9642: LANGUAGE pragma synonyms -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:7 nomeata]: > How about putting these aliases into the package database? But then loading a module from the package into GHCi would require knowing about aliases in the `.cabal` file. > (This opens the way to other `cabal` flags to be used here, e.g. compiler flags to load a specific plugin, which might be very useful, but let?s not go there with this proposal yet.) That's a feature I would like to see. In the past I struggled a lot because I had to duplicate in the `benchmark` section all language extensions and compilation options specified in `library` section. But then again this is a Cabal feature request, not GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 07:47:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 07:47:34 -0000 Subject: [GHC] #9642: LANGUAGE pragma synonyms In-Reply-To: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> References: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> Message-ID: <061.fbdebcd155792ce00026c989e8787275@haskell.org> #9642: LANGUAGE pragma synonyms -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > But then loading a module from the package into GHCi would require knowing about aliases in the .cabal file. True, it would only help providing synonyms across package boundaries (or imaginably when using `cabal repl` using some weird trick), not when trying to re-use a synonym within a package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 07:55:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 07:55:11 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.3c46f36eebdb1dc3939860940e36f3cd@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:8 dfeuer]: > it seems that in the wild (all over the library source), `isTrue#` is typically used as a function for converting from `Int#`, produced by a comparison operator, to `Bool`, rather than as a validity test for `True`. I have yet to see any explanation of why that is appropriate. Right, I see what you mean. So the only way the `isTrue#` and `isFalse#` functions are "safe" is because they promise to do what their names imply. You've focused on `isTrue#`, which indeed is identical to `tagToEnum#` but this is definitely not the case with `isFalse#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 09:55:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 09:55:34 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.5a67ff3a50a3d8a325d898e580135a7d@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dreixel): * milestone: ? => 7.10.1 Comment: I'm working on this in branch wip/T5462. Coding is complete, now I just need to write the user manual description and an informative wiki page. See 7a4cdef85b0fa03a22fda595ac92870465d8c727 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 12:28:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 12:28:58 -0000 Subject: [GHC] #9646: Strange performance bug Message-ID: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> #9646: Strange performance bug -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've been chasing a weird performance bug for about a week now. I've reduced the testcase to the following git repo: https://github.com/erikd/ghc-perfbug-test The Readme.md file in that repo contains an explanation of how to reproduce the issue. The benchmark program in the repo uses Criterion to test the performance of one particular function. Running the program in a particular way results into two significanlty different results. The commands are: {{{ make clean bench-integer.html cp -f bench-integer.html bench-integer-slow.html touch New3/GHC/Integer/Natural.hs && make bench-integer.html }}} The results for one function in the file `New3/GHC/Integer/Natural.hs` is 8 times slower in the first test that the second while the other test function always executes at about the speed. I haven't been able to test this with ghc-7.6.3 because the code uses `isTrue#` which isn't available in 7.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 13:50:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 13:50:21 -0000 Subject: [GHC] #9646: Strange performance bug In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.094f369842664ccb271f5a9627a8a380@haskell.org> #9646: Strange performance bug -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): `isTrue#` is an alias to `tagToEnum#`, so you can convert your code to GHC 7.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 14:06:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 14:06:24 -0000 Subject: [GHC] #9647: allocation of 10790760 bytes too large Message-ID: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> #9647: allocation of 10790760 bytes too large -------------------------------------+------------------------------------- Reporter: mirko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: run time | Operating System: Windows insufficient memory | Type of failure: Incorrect Architecture: x86_64 (amd64) | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I got an error message and invitation to submit a bug report. So here is the error message first, followed by my description of what happened. C:\Users\Owner\Documents\hs>ghc -o void void.hs -rtsopts [1 of 1] Compiling Main ( void.hs, void.o ) Linking void.exe ... C:\Users\Owner\Documents\hs>void +RTS -K400M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug C:\Users\Owner\Documents\hs>void +RTS -K40000M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Description of what happened. I gave my program really large numbers. It contains the following line: rr = (of40)*(r250^3041) In the above of40 is (if I remember correctly) the product of the first 40000 odd primes. I computed it with reduce (a computer algebra system) which saved the result (as an explicitly written out number in decimal notation), which I copied and inserted in my hs file, initializing of40 with its value. In the file it takes 2457 rows, 1024 cols, so it appears to be about 2 515 968 (that is two million+) decimal digits. As seen it is multiplied by r250^3041, here r250 is a 250-digit number so r250^3041 is about 760 250 (seven hundred sixty thousand+) decimal digits, so the product rr = (of40)*(r250^3041) seems to be more than 3 000 000 (three million+) decimal digits. I tried to compile it yesterday, I did get an error message from the compiler: I do not remember exactly what it was, I may try to reproduce it later and include it, but it was something along the lines of insufficient amount of memory. I run a Hewlett-Packard HPE 500y, upgraded to 16 Gb RAM (the max it would take), Windows 7, AMD Phenom(tm) II X6 1045T Processor 2.70 GHz (6 core). So yesterday after I got the first error message I increased the paging file size from automatic to 32768 Mb initial, and 65536 Mb max. Then tried to compile again, the compiler gradually took more and more memory (I was watching the performance using the Task Manager) so it gradually went up to using all 16 Gb of RAM, and stayed there for I think at least 40 min, could have been more than an hour (or even 2 hours, sorry can't quite remember). At some point it seemed the computer froze, the task manager stopped showing any activity, but I did not attempt to immediately restart it, the mouse would not respond anyway, and in a few minutes it fixed itself, it seemed to continue compiling, after which it eventually gave up and complained about insufficient amount of memory again. So this morning I increased the paging file to initial size 49152 Mb, max size 196608 Mb (I don't know if such big numbers make sense but I tried). I tried to compile again starting around 9am, left my apt at around 4pm and the compiler had not yet finished, and came back after midnight, the compiler had finished. It had produced a big exe file (I see now, around 9 pm, so it must have kept compiling for around 12 hours): 09/27/2014 09:38 PM 20,602,960 void.exe AVG (antivirus) claimed that this file was a threat and refused to let me run it, so I had to disable AVG, after which I got the error messages as already enclosed at the beginning of this description. The Paging file reports as: Recommended 24574 Mb, Currently allocated: 163765 Mb. Note I gave the options -rtsopts to the compiler, I do not remember anymore what they mean, and whether they are valid (or perhaps not used anymore), I got them from a webpage perhaps a couple of years ago and at that time they made sense, so I just kept using them. I also gave the option +RTS -K400M -RTS when I tried to execute the compiled program, and then +RTS -K40000M -RTS, both versions generated the error messages shown above. I tend to believe that giving Haskell such large numbers inside the .hs file explains all of the above problems, it might even be a bit surprising it went so far before it finally gave up. But I do not really know, so let me just report it. So I changed the paging file back to automatic, and I am compiling the same file (after renaming it) to try to reproduce the error message that I got yesterday (or rather the other day, now being after midnight). It has been compiling for about 4 min so far, nothing really visible, memory usage stays at 1.28 Gb (where it was before I started compiling). I don't quite remember what happened the first time when I tried to compile, I think I got the error message (about insufficient amount of memory) immediately, or almost immediately. This does not happen now, I wonder if the computer took into account that I changed the paging file back to automatic, I may need to restart to make sure. Well, ok, 13 min after it started compiling, the memory usage started going up gradually. It goes from e.g. 13.9 to 14 Gb in about a second or two. So in about 2 min it went from 1.28 to 15.9 Gb, and now stays there (I do not know how to interpret all that Task Manager shows me). I may not be able to reproduce the first error message: At that time I was running 5 copies of reduce, each busy multiplying numbers for some hours. Right now I am only running the GHC by itself, so no other load. It is running for about 23 min now, the last 6 of which the memory usage stays at 15.9 Gb. My computer may have learned to increase the paging file on its own. The computer refuses to give up this time, but I can't wait, going to bed is long overdue, if it generates an error message I'll copy it in the morning. Well, memory usage decreased a bit to 15.1, this happened after it stayed at 15.9 for about 15 min. It I remember correctly what had happened the other day, it will increase again, and then give an error message. It's at 15.3 Gb for about 3 min now. On the other hand the processor is doing almost nothing, going between 0% and 1%. Memory 15.4, 15.8, processor went up to 16% to 17% (which is = 1 out of 6 cores), memory 15.9, this is about 40 min after it started compiling and about 23 min after it went up to 15.9 Gb (15.8 presently). I should perhaps be patient and wait for the compiler to give up and give me an error message that I could copy, but I do not have the patience to do that: Again the original error message was something to the effect that the compiler refused to work because of insufficient amount of memory. I kept trying to compile, so apparently the compiler tried to be nice to me, and eventually compiled my program in 9 hours, after which when I tried to execute it, I was invited to write this report. It keeps compiling right now, at 16% (1 of 6 cores) processor, and 15.9 Gb memory usage, for about 47 min (30 min at 15.9). P.S. Thanks for Richard Eisenberg and Herbert Valerio Riedel for replying to my email. I initially had problems, trying to register and submit a new bug report, the BotScout stopped me, and it was too late at night to try to figure it, so I just emailed Richard in my frustration. Now, BotScout may not be the culprit: I did not read carefully what it asked me to do, and it was something like Evaluate `(!!6) ...' My knowledge of Haskell is rather superficial (I use it since it compiles and is relatively fast, and does not need an extra library to work with large numbers), so I have to often consult the tutorial for simple constructs. I have had some previous experience with Common Lisp (or Scheme, a course taken 12 years ago) and in Lisp there is a command "evaluate", and also single quotation marks are used within the language occasionally. So, I just copied the entire line Evaluate `(!!6) (whatever it was)' and pasted it in the interpreter which gave me some nonsense which I sent back to BotScout. BotScout then gave me a second chance, and I do not quite remember if I tried to be more careful, perhaps not, so BotScout wouldn't even let me try anymore after that (even if I started from scratch ... perhaps it remembered me). After that happened I copied only the (!!6), etc, and the my GHC interpreter did evaluate something meaningful (a single number, no error message). I just didn't want to spend the time to think that late at night, and at first it seemed to me that the word Evaluate might have been part of a Haskell expression. I question if the above (perhaps too lengthy) report is of any use, but again, I follow the instruction, if in doubt, submit it. Thank you again! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 15:03:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 15:03:37 -0000 Subject: [GHC] #9648: ghci fails to reload after deleting/creating an imported module Message-ID: <051.6a800ad064a7e9508a8fdca22e1c117b@haskell.org> #9648: ghci fails to reload after deleting/creating an imported module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If you start GHCi with a 2 module program, delete the child module, reload, you get an error (as expected). If you recreate the child module and reload, it reloads the dependent module but erroneously claims that parent can't find the child. Note that if you rename the child to something else, then rename it back, then the test works - so it seems the reappearance and the file stamp confuses ghci. Spotted while working on ghcid: https://github.com/ndmitchell/ghcid {{{ $ echo module Util where > Util.hs $ echo import Util; main = print 1 > Main.hs $ ghci Main.hs GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 2] Compiling Util ( Util.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) Ok, modules loaded: Util, Main. *Main> :!del Util.hs *Main> :r Main.hs:1:8: Could not find module `Util' It is a member of the hidden package `ghc-7.8.3'. Use -v to see a list of the files searched for. Failed, modules loaded: Util, Main. *Main> :!echo module Util where > Util.hs *Main> :r [1 of 2] Compiling Util ( Util.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) [Util changed] Main.hs:1:1: Failed to load interface for `Util' It is a member of the hidden package `ghc-7.8.3'. Use -v to see a list of the files searched for. Failed, modules loaded: Util. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 15:04:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 15:04:02 -0000 Subject: [GHC] #9648: ghci fails to reload after deleting/creating an imported module In-Reply-To: <051.6a800ad064a7e9508a8fdca22e1c117b@haskell.org> References: <051.6a800ad064a7e9508a8fdca22e1c117b@haskell.org> Message-ID: <066.110e6e8681f183e12ee321a14214b9b0@haskell.org> #9648: ghci fails to reload after deleting/creating an imported module -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by NeilMitchell: Old description: > If you start GHCi with a 2 module program, delete the child module, > reload, you get an error (as expected). If you recreate the child module > and reload, it reloads the dependent module but erroneously claims that > parent can't find the child. > > Note that if you rename the child to something else, then rename it back, > then the test works - so it seems the reappearance and the file stamp > confuses ghci. Spotted while working on ghcid: > https://github.com/ndmitchell/ghcid > > {{{ > $ echo module Util where > Util.hs > > $ echo import Util; main = print 1 > Main.hs > > $ ghci Main.hs > GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > [1 of 2] Compiling Util ( Util.hs, interpreted ) > [2 of 2] Compiling Main ( Main.hs, interpreted ) > Ok, modules loaded: Util, Main. > *Main> :!del Util.hs > *Main> :r > > Main.hs:1:8: > Could not find module `Util' > It is a member of the hidden package `ghc-7.8.3'. > Use -v to see a list of the files searched for. > Failed, modules loaded: Util, Main. > *Main> :!echo module Util where > Util.hs > *Main> :r > [1 of 2] Compiling Util ( Util.hs, interpreted ) > [2 of 2] Compiling Main ( Main.hs, interpreted ) [Util > changed] > > Main.hs:1:1: > Failed to load interface for `Util' > It is a member of the hidden package `ghc-7.8.3'. > Use -v to see a list of the files searched for. > Failed, modules loaded: Util. > }}} New description: If you start GHCi with a 2 module program, delete the child module, reload, you get an error (as expected). If you recreate the child module and reload, it reloads the child module but erroneously claims that parent can't find the child. Note that if you rename the child to something else, then rename it back, then the test works - so it seems the reappearance and the file stamp confuses ghci. Spotted while working on ghcid: https://github.com/ndmitchell/ghcid {{{ $ echo module Util where > Util.hs $ echo import Util; main = print 1 > Main.hs $ ghci Main.hs GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 2] Compiling Util ( Util.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) Ok, modules loaded: Util, Main. *Main> :!del Util.hs *Main> :r Main.hs:1:8: Could not find module `Util' It is a member of the hidden package `ghc-7.8.3'. Use -v to see a list of the files searched for. Failed, modules loaded: Util, Main. *Main> :!echo module Util where > Util.hs *Main> :r [1 of 2] Compiling Util ( Util.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) [Util changed] Main.hs:1:1: Failed to load interface for `Util' It is a member of the hidden package `ghc-7.8.3'. Use -v to see a list of the files searched for. Failed, modules loaded: Util. }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 15:05:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 15:05:58 -0000 Subject: [GHC] #9648: ghci fails to reload after deleting/creating an imported module In-Reply-To: <051.6a800ad064a7e9508a8fdca22e1c117b@haskell.org> References: <051.6a800ad064a7e9508a8fdca22e1c117b@haskell.org> Message-ID: <066.482693804715ae419a97d2156096af53@haskell.org> #9648: ghci fails to reload after deleting/creating an imported module -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 16:18:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 16:18:41 -0000 Subject: [GHC] #9647: allocation of 10790760 bytes too large In-Reply-To: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> References: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> Message-ID: <059.1b9ad6543c03b15710304ee6331dba3b@haskell.org> #9647: allocation of 10790760 bytes too large -------------------------------------+------------------------------------- Reporter: mirko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: run time Operating System: Windows | insufficient memory Type of failure: Incorrect | Architecture: x86_64 (amd64) warning at compile-time | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Please edit your description to remove extraneous information about the bug reporting process?you can report a separate bug against the TRAC component in the "component" drop-down if you like. I don't know much about GHC's handling of huge Integers, but I believe it uses GMP, which can barf when they're ''too'' large, which yours may very well be. GMP also appears to lack any sort of graceful error handling mechanism, and as I understand it there are dependency issues preventing GHC's code from catching the hardware faults GMP throws. Specifically, I believe the code implementing `Integer` is very low down in the dependency stack, so it doesn't have access to fancy error-management mechanisms. GHC handles this partially by performing some sanity checks before handing the calculation off, but this sanity checking isn't enough to prevent crashes resulting from calculations reaching overly-large numbers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 16:46:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 16:46:28 -0000 Subject: [GHC] #9646: Strange performance bug In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.79f2d7ac9e271364a41e004c784ddda1@haskell.org> #9646: Strange performance bug -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I don't know what's going on, but I'm curious whether there might be some sort of interference from `make` or associated OS or CPU stuff. Have you tried running the benchmarks separately from the compilation process? Another thing to experiment with is reversing the order of the Criterion benchmarks to see if the slowness follows the position in the benchmark list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 17:49:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 17:49:34 -0000 Subject: [GHC] #9649: symbols should/might be type level lists of chars Message-ID: <045.7eed415602713344419f19bba35ae3f7@haskell.org> #9649: symbols should/might be type level lists of chars -------------------------------------+------------------------------------- Reporter: ibotty | Owner: ibotty Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I thought I had seen that feature request in trac but did not find it. Sorry if I am wrong. A simple use case might be a type safe routing framework, e.g. {{{ get :: Route "/a/:id" $ do idA <- param :: Param "idA" ... }}} I spoke with pedro at hacberlin last weekend and he told me simonp and iavor might tell me where to start looking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 17:49:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 17:49:33 -0000 Subject: [GHC] #9603: getArgs path transformation is broken on Windows In-Reply-To: <045.e61ab36b85802c1081d92cfe8af2fe04@haskell.org> References: <045.e61ab36b85802c1081d92cfe8af2fe04@haskell.org> Message-ID: <060.bd7f23184515374bb76a0da27015e124@haskell.org> #9603: getArgs path transformation is broken on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: #9218 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr, ekmett (removed) * resolution: => duplicate * status: new => closed * component: libraries/base => Build System * related: => #9218 Comment: Sounds like doing #9218 will solve this issue as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 18:06:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 18:06:23 -0000 Subject: [GHC] #9637: Type level programming needs an error function In-Reply-To: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> References: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> Message-ID: <062.573f6ce1e7ee3af1e666e14aa85c4426@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by augustss): Here's what I'm using now, and it works nicely. But better names would be nice. {{{#!hs type family Error (a :: k1) :: k2 where { } data ErrorAnd (a :: k1) (b :: k2) }}} When the type checker encounters the Error function it generates the error message according to the following pseudo code: {{{#!hs flatten (Symbol s) = s flatten (ErrorAnd t1 t2) = flatten t1 ++ flatten t2 flatten t = prettyPrint t }}} So for instance `Error "Oh noes!"` will generate the error message "Oh noes!". And {{{Error ("Mismatch between " `ErrorAnd` t1 `ErrorAnd` " and " `ErrorAnd` t2)}}} will generate "Mismatch between ... and ...", where ... are the pretty printing of the types t1 and t2 respectively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 19:05:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 19:05:46 -0000 Subject: [GHC] #9647: allocation of 10790760 bytes too large In-Reply-To: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> References: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> Message-ID: <059.0296e29f4f6d84db381e831ff8de2ebf@haskell.org> #9647: allocation of 10790760 bytes too large -------------------------------------+------------------------------------- Reporter: mirko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: run time Operating System: Windows | insufficient memory Type of failure: Incorrect | Architecture: x86_64 (amd64) warning at compile-time | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mirko): Here is the error message first, followed by my description of what happened. hs> ghc -o void void.hs -rtsopts [1 of 1] Compiling Main ( void.hs, void.o ) Linking void.exe ... hs> void +RTS -K400M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug hs> void +RTS -K40000M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Description of what happened: I gave my program really large numbers. It contains the following line: rr = (of40)*(r^3041) where of40 is an integer which has about 2 515 968 (that is two million+) decimal digits (explicitly written out and initialized in the .hs file). In addition, of40 is multiplied by (r to the power or 3041), where r is a 250-digit number so (r to the power or 3041) has about 760 250 (seven hundred sixty thousand+) decimal digits. This makes the product rr = (of40)*(r^3041) to have more than 3 000 000 (three million+) decimal digits. I tried to compile it three times, twice unsuccessful (insufficient amount of memory during compilation), and the third time successful, after 12 hours work by the compiler, and me increasing the paging file to initial size 49152 Mb, max size 196608 Mb. (At the end of compilation the Paging file reported as: Recommended 24574 Mb, Currently allocated: 163765 Mb.) I run a Hewlett-Packard HPE 500y, upgraded to 16 Gb RAM, Windows 7, AMD Phenom(tm) II X6 1045T Processor 2.70 GHz (6 core). The compiler produced a big exe file: 09/27/2014 09:38 PM 20,602,960 void.exe When I tried to run the exe file I got the error messages as already enclosed at the beginning of this description. Most of the time during compilation the computer used all of the available memory. Note that I gave the options -rtsopts to the compiler, and the option +RTS -K400M -RTS when I tried to execute the compiled program (I believe this is some kind of a request for more memory), and one more attempt with +RTS -K40000M -RTS, both versions generated the error messages shown above. P.S. Thanks to Richard Eisenberg and Herbert Valerio Riedel for replying to my email, after BotScout kept me from submitting my report. Apparently I passed the evaluation-captcha (on my second attempt) but nevertheless BotScout insisted I was spam. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 19:12:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 19:12:10 -0000 Subject: [GHC] #9647: allocation of 10790760 bytes too large In-Reply-To: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> References: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> Message-ID: <059.634c89e03f15913fa87160a048087224@haskell.org> #9647: allocation of 10790760 bytes too large -------------------------------------+------------------------------------- Reporter: mirko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: run time Operating System: Windows | insufficient memory Type of failure: Incorrect | Architecture: x86_64 (amd64) warning at compile-time | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Old description: > I got an error message and invitation to submit a bug > report. So here is the error message first, followed > by my description of what happened. > > C:\Users\Owner\Documents\hs>ghc -o void void.hs -rtsopts > [1 of 1] Compiling Main ( void.hs, void.o ) > Linking void.exe ... > > C:\Users\Owner\Documents\hs>void +RTS -K400M -RTS > void.txt > void: internal error: allocation of 10790760 bytes too large > (GHC should have complained at compile-time) > (GHC version 7.8.3 for x86_64_unknown_mingw32) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > > C:\Users\Owner\Documents\hs>void +RTS -K40000M -RTS > void.txt > void: internal error: allocation of 10790760 bytes too large > (GHC should have complained at compile-time) > (GHC version 7.8.3 for x86_64_unknown_mingw32) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > > Description of what happened. > I gave my program really large numbers. > It contains the following line: > > rr = (of40)*(r250^3041) > > In the above of40 is (if I remember correctly) the product > of the first 40000 odd primes. I computed it with reduce > (a computer algebra system) which saved the result (as an > explicitly written out number in decimal notation), which > I copied and inserted in my hs file, initializing of40 with > its value. In the file it takes 2457 rows, 1024 cols, so > it appears to be about 2 515 968 (that is two million+) > decimal digits. As seen it is multiplied by r250^3041, > here r250 is a 250-digit number so r250^3041 is about > 760 250 (seven hundred sixty thousand+) decimal digits, > so the product rr = (of40)*(r250^3041) seems to be more > than 3 000 000 (three million+) decimal digits. > > I tried to compile it yesterday, I did get an error > message from the compiler: I do not remember exactly > what it was, I may try to reproduce it later and include > it, but it was something along the lines of insufficient > amount of memory. I run a Hewlett-Packard HPE 500y, > upgraded to 16 Gb RAM (the max it would take), Windows 7, > AMD Phenom(tm) II X6 1045T Processor 2.70 GHz (6 core). > So yesterday after I got the first error message I increased > the paging file size from automatic to 32768 Mb initial, and > 65536 Mb max. Then tried to compile again, the compiler > gradually took more and more memory (I was watching the performance > using the Task Manager) so it gradually went up to using > all 16 Gb of RAM, and stayed there for I think at least 40 min, > could have been more than an hour (or even 2 hours, sorry > can't quite remember). At some point it seemed the computer > froze, the task manager stopped showing any activity, but I > did not attempt to immediately restart it, the mouse would not > respond anyway, and in a few minutes it fixed itself, it > seemed to continue compiling, after which it eventually > gave up and complained about insufficient amount > of memory again. So this morning I increased > the paging file to initial size 49152 Mb, > max size 196608 Mb (I don't know if such big numbers > make sense but I tried). I tried to compile again > starting around 9am, left my apt at around 4pm and > the compiler had not yet finished, and came back after > midnight, the compiler had finished. It had produced > a big exe file (I see now, around 9 pm, so it must > have kept compiling for around 12 hours): > 09/27/2014 09:38 PM 20,602,960 void.exe > AVG (antivirus) claimed that this file was a threat and > refused to let me run it, so I had to disable AVG, > after which I got the error messages as already > enclosed at the beginning of this description. > The Paging file reports as: Recommended 24574 Mb, > Currently allocated: 163765 Mb. > > Note I gave the options -rtsopts to the compiler, > I do not remember anymore what they mean, and whether > they are valid (or perhaps not used anymore), I got > them from a webpage perhaps a couple of years ago > and at that time they made sense, so I just kept using them. > I also gave the option +RTS -K400M -RTS when I tried > to execute the compiled program, and then > +RTS -K40000M -RTS, both versions generated the error > messages shown above. I tend to believe that giving > Haskell such large numbers inside the .hs file explains > all of the above problems, it might even be a bit > surprising it went so far before it finally gave up. > But I do not really know, so let me just report it. > > So I changed the paging file back to automatic, and > I am compiling the same file (after renaming it) to > try to reproduce the error message that I got yesterday > (or rather the other day, now being after midnight). > It has been compiling for about 4 min so far, nothing > really visible, memory usage stays at 1.28 Gb (where > it was before I started compiling). I don't quite remember > what happened the first time when I tried to compile, > I think I got the error message (about insufficient > amount of memory) immediately, or almost immediately. > This does not happen now, I wonder if the computer > took into account that I changed the paging file > back to automatic, I may need to restart to make sure. > Well, ok, 13 min after it started compiling, the memory > usage started going up gradually. It goes from e.g. > 13.9 to 14 Gb in about a second or two. So in about > 2 min it went from 1.28 to 15.9 Gb, and now stays there > (I do not know how to interpret all that Task Manager shows me). > I may not be able to reproduce the first error message: > At that time I was running 5 copies of reduce, each > busy multiplying numbers for some hours. Right now > I am only running the GHC by itself, so no other load. > It is running for about 23 min now, the last 6 of which > the memory usage stays at 15.9 Gb. My computer may > have learned to increase the paging file on its own. > The computer refuses to give up this time, but I can't > wait, going to bed is long overdue, if it generates an > error message I'll copy it in the morning. Well, memory > usage decreased a bit to 15.1, this happened after it stayed > at 15.9 for about 15 min. It I remember correctly what had > happened the other day, it will increase again, and then give > an error message. It's at 15.3 Gb for about 3 min now. On the > other hand the processor is doing almost nothing, going between > 0% and 1%. Memory 15.4, 15.8, processor went up to 16% to 17% > (which is = 1 out of 6 cores), > memory 15.9, this is about 40 min after it started compiling > and about 23 min after it went up to 15.9 Gb (15.8 presently). > I should perhaps be patient and wait for the compiler to give up > and give me an error message that I could copy, but I do not have > the patience to do that: Again the original error message was > something to the effect that the compiler refused to work > because of insufficient amount of memory. I kept trying to > compile, so apparently the compiler tried to be nice to me, > and eventually compiled my program in 9 hours, after which > when I tried to execute it, I was invited to write this report. > It keeps compiling right now, at 16% (1 of 6 cores) processor, > and 15.9 Gb memory usage, for about 47 min (30 min at 15.9). > > P.S. Thanks for Richard Eisenberg and Herbert Valerio Riedel > for replying to my email. I initially had problems, trying > to register and submit a new bug report, the BotScout > stopped me, and it was too late at night to try to figure it, > so I just emailed Richard in my frustration. Now, BotScout > may not be the culprit: I did not read carefully what > it asked me to do, and it was something like > Evaluate `(!!6) ...' > My knowledge of Haskell is rather superficial (I use it since it > compiles and is relatively fast, and does not need an extra library > to work with large numbers), so I have to often consult the > tutorial for simple constructs. I have had some previous > experience with Common Lisp (or Scheme, a course taken 12 > years ago) and in Lisp there is a command "evaluate", and > also single quotation marks are used within the language > occasionally. So, I just copied the entire line > Evaluate `(!!6) (whatever it was)' > and pasted it in the interpreter which gave me some > nonsense which I sent back to BotScout. BotScout then > gave me a second chance, and I do not quite remember > if I tried to be more careful, perhaps not, so BotScout > wouldn't even let me try anymore after that (even if > I started from scratch ... perhaps it remembered me). > After that happened I copied only the (!!6), etc, and > the my GHC interpreter did evaluate something meaningful > (a single number, no error message). I just didn't want > to spend the time to think that late at night, and > at first it seemed to me that the word Evaluate > might have been part of a Haskell expression. > I question if the above (perhaps too lengthy) report > is of any use, but again, I follow the instruction, > if in doubt, submit it. Thank you again! New description: Here is the error message first, followed by my description of what happened. hs> ghc -o void void.hs -rtsopts [1 of 1] Compiling Main ( void.hs, void.o ) Linking void.exe ... hs> void +RTS -K400M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug hs> void +RTS -K40000M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Description of what happened: I gave my program really large numbers. It contains the following line: rr = (of40)*(r3041) where of40 is an integer which has about 2 515 968 (that is two million+) decimal digits (explicitly written out and initialized in the .hs file). In addition, of40 is multiplied by (r to the power or 3041), where r is a 250-digit number so (r to the power or 3041) has about 760 250 (seven hundred sixty thousand+) decimal digits. This makes the product rr = (of40)*(r3041) to have more than 3 000 000 (three million+) decimal digits. I tried to compile it three times, twice unsuccessful (insufficient amount of memory during compilation), and the third time successful, after 12 hours work by the compiler, and me increasing the paging file to initial size 49152 Mb, max size 196608 Mb. (At the end of compilation the Paging file reported as: Recommended 24574 Mb, Currently allocated: 163765 Mb.) I run a Hewlett-Packard HPE 500y, upgraded to 16 Gb RAM, Windows 7, AMD Phenom(tm) II X6 1045T Processor 2.70 GHz (6 core). The compiler produced a big exe file: 09/27/2014 09:38 PM 20,602,960 void.exe When I tried to run the exe file I got the error messages as already enclosed at the beginning of this description. Most of the time during compilation the computer used all of the available memory. Note that I gave the options -rtsopts to the compiler, and the option +RTS -K400M -RTS when I tried to execute the compiled program (I believe this is some kind of a request for more memory), and one more attempt with +RTS -K40000M -RTS, both versions generated the error messages shown above. P.S. Thanks to Richard Eisenberg and Herbert Valerio Riedel for replying to my email, after BotScout kept me from submitting my report. Apparently I passed the evaluation-captcha (on my second attempt) but nevertheless BotScout insisted I was spam. -- Comment (by mirko): Here is the error message first, followed by my description of what happened. hs> ghc -o void void.hs -rtsopts [1 of 1] Compiling Main ( void.hs, void.o ) Linking void.exe ... hs> void +RTS -K400M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug hs> void +RTS -K40000M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Description of what happened: I gave my program really large numbers. It contains the following line: rr = (of40)*(r^3041) where of40 is an integer which has about 2 515 968 (that is two million+) decimal digits (explicitly written out and initialized in the .hs file). In addition, of40 is multiplied to (r to the power or 3041), where r is a 250-digit number so (r to the power or 3041) has about 760 250 (seven hundred sixty thousand+) decimal digits. This makes the product rr = (of40)*(r^3041) to have more than 3 000 000 (three million+) decimal digits. I tried to compile it three times, twice unsuccessful (insufficient amount of memory during compilation), and the third time successful, after 12 hours work by the compiler, and me increasing the paging file to initial size 49152 Mb, max size 196608 Mb. (At the end of compilation the Paging file reported as: Recommended 24574 Mb, Currently allocated: 163765 Mb.) I run a Hewlett-Packard HPE 500y, upgraded to 16 Gb RAM, Windows 7, AMD Phenom(tm) II X6 1045T Processor 2.70 GHz (6 core). The compiler produced a big exe file: 09/27/2014 09:38 PM 20,602,960 void.exe When I tried to run the exe file I got the error messages as already enclosed at the beginning of this description. Most of the time during compilation the computer used all of the available memory. Note that I gave the options -rtsopts to the compiler, and the option +RTS -K400M -RTS when I tried to execute the compiled program (I believe this is some kind of a request for more memory), and one more attempt with +RTS -K40000M -RTS, both versions generated the error messages shown above. P.S. Thanks to Richard Eisenberg and Herbert Valerio Riedel for replying to my email, after BotScout kept me from submitting my report. Apparently I passed the evaluation-captcha (on my second attempt) but nevertheless BotScout insisted I was spam. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 19:16:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 19:16:13 -0000 Subject: [GHC] #9647: allocation of 10790760 bytes too large In-Reply-To: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> References: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> Message-ID: <059.1edca0cb215459658ce192c965485384@haskell.org> #9647: allocation of 10790760 bytes too large -------------------------------------+------------------------------------- Reporter: mirko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: run time Operating System: Windows | insufficient memory Type of failure: Incorrect | Architecture: x86_64 (amd64) warning at compile-time | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Description changed by mirko: Old description: > Here is the error message first, followed > by my description of what happened. > > hs> ghc -o void void.hs -rtsopts > [1 of 1] Compiling Main ( void.hs, void.o ) > Linking void.exe ... > > hs> void +RTS -K400M -RTS > void.txt > void: internal error: allocation of 10790760 bytes too large > (GHC should have complained at compile-time) > > (GHC version 7.8.3 for x86_64_unknown_mingw32) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > > hs> void +RTS -K40000M -RTS > void.txt > void: internal error: allocation of 10790760 bytes too large > (GHC should have complained at compile-time) > > (GHC version 7.8.3 for x86_64_unknown_mingw32) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > > Description of what happened: > I gave my program really large numbers. > It contains the following line: > > rr = (of40)*(r3041) > > where of40 is an integer which has about 2 515 968 > (that is two million+) decimal digits (explicitly > written out and initialized in the .hs file). > In addition, of40 is multiplied by (r to the power or 3041), > where r is a 250-digit number so (r to the power or 3041) > has about 760 250 (seven hundred sixty thousand+) decimal digits. > This makes the product > > rr = (of40)*(r3041) > > to have more than 3 000 000 (three million+) decimal digits. > > I tried to compile it three times, twice unsuccessful > (insufficient amount of memory during compilation), > and the third time successful, after 12 hours work by > the compiler, and me increasing the paging file to > initial size 49152 Mb, max size 196608 Mb. > (At the end of compilation the Paging file reported as: > Recommended 24574 Mb, Currently allocated: 163765 Mb.) > I run a Hewlett-Packard HPE 500y, upgraded to 16 Gb RAM, > Windows 7, AMD Phenom(tm) II X6 1045T Processor 2.70 GHz (6 core). > The compiler produced a big exe file: > 09/27/2014 09:38 PM 20,602,960 void.exe > When I tried to run the exe file I got the error messages > as already enclosed at the beginning of this description. > Most of the time during compilation the computer used > all of the available memory. > > Note that I gave the options -rtsopts to the compiler, > and the option +RTS -K400M -RTS when I tried > to execute the compiled program (I believe this is > some kind of a request for more memory), and one more > attempt with +RTS -K40000M -RTS, both versions generated > the error messages shown above. > > P.S. Thanks to Richard Eisenberg and Herbert Valerio Riedel > for replying to my email, after BotScout kept me from > submitting my report. Apparently I passed the > evaluation-captcha (on my second attempt) but > nevertheless BotScout insisted I was spam. New description: Here is the error message first, followed by my description of what happened. hs> ghc -o void void.hs -rtsopts [1 of 1] Compiling Main ( void.hs, void.o ) Linking void.exe ... hs> void +RTS -K400M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug hs> void +RTS -K40000M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Description of what happened: I gave my program really large numbers. It contains the following line: rr = (of40)*(r^3041) where of40 is an integer which has about 2 515 968 (that is two million+) decimal digits (explicitly written out and initialized in the .hs file). In addition, of40 is multiplied by (r to the power or 3041), where r is a 250-digit number so (r to the power or 3041) has about 760 250 (seven hundred sixty thousand+) decimal digits. This makes the product rr = (of40)*(r^3041) to have more than 3 000 000 (three million+) decimal digits. I tried to compile it three times, twice unsuccessful (insufficient amount of memory during compilation), and the third time successful, after 12 hours work by the compiler, and me increasing the paging file to initial size 49152 Mb, max size 196608 Mb. (At the end of compilation the Paging file reported as: Recommended 24574 Mb, Currently allocated: 163765 Mb.) I run a Hewlett-Packard HPE 500y, upgraded to 16 Gb RAM, Windows 7, AMD Phenom(tm) II X6 1045T Processor 2.70 GHz (6 core). The compiler produced a big exe file: 09/27/2014 09:38 PM 20,602,960 void.exe When I tried to run the exe file I got the error messages as already enclosed at the beginning of this description. Most of the time during compilation the computer used all of the available memory. Note that I gave the options -rtsopts to the compiler, and the option +RTS -K400M -RTS when I tried to execute the compiled program (I believe this is some kind of a request for more memory), and one more attempt with +RTS -K40000M -RTS, both versions generated the error messages shown above. P.S. Thanks to Richard Eisenberg and Herbert Valerio Riedel for replying to my email, after BotScout kept me from submitting my report. Apparently I passed the evaluation-captcha (on my second attempt) but nevertheless BotScout insisted I was spam. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 19:33:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 19:33:14 -0000 Subject: [GHC] #9259: GHCi should list its available command line options In-Reply-To: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> References: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> Message-ID: <063.dd3446abcef56abb3ac9644223a94a1f@haskell.org> #9259: GHCi should list its available command line options -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Driver | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by kolmodin): Making `--interactive` and `--show-options` work together is simple, just a few more lines to `setMode`. The time consuming part with this task is to cleanly separate which flags work in GHC and which work in GHCi. The flags are defined in a few different places; * `ModeFlags` defined in `ghc/Main.hs` which apply to both GHC and GHCi. * `StaticFlags` defined in `compiler/main/StaticFlags.hs` which applies to both GHC and GHCi. * DynFlags defined in `compiler/main/DynFlags.hs`. There are a few different kinds of flags here (dynflags, package flags, fflags, fwarn, ...), each of which where some are for GHC and some for GHCi. For some flags there is code guarding to make sure you don't mix them, like together with `--interactive` you cannot use `-prof`, `-threaded`, `-unreg`, `-debug` or `-ticky`. For other flags there is no such code, and it's not always obvious where each flag has effect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 19:52:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 19:52:36 -0000 Subject: [GHC] #9647: allocation of 10790760 bytes too large In-Reply-To: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> References: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> Message-ID: <059.24c0d3ac791bd5eff772afa01c90906f@haskell.org> #9647: allocation of 10790760 bytes too large -------------------------------------+------------------------------------- Reporter: mirko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: run time Operating System: | insufficient memory Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * failure: Incorrect warning at compile-time => Compile-time crash * os: Windows => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple Old description: > Here is the error message first, followed > by my description of what happened. > > hs> ghc -o void void.hs -rtsopts > [1 of 1] Compiling Main ( void.hs, void.o ) > Linking void.exe ... > > hs> void +RTS -K400M -RTS > void.txt > void: internal error: allocation of 10790760 bytes too large > (GHC should have complained at compile-time) > > (GHC version 7.8.3 for x86_64_unknown_mingw32) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > > hs> void +RTS -K40000M -RTS > void.txt > void: internal error: allocation of 10790760 bytes too large > (GHC should have complained at compile-time) > > (GHC version 7.8.3 for x86_64_unknown_mingw32) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > > Description of what happened: > I gave my program really large numbers. > It contains the following line: > > rr = (of40)*(r^3041) > > where of40 is an integer which has about 2 515 968 > (that is two million+) decimal digits (explicitly > written out and initialized in the .hs file). > In addition, of40 is multiplied by (r to the power or 3041), > where r is a 250-digit number so (r to the power or 3041) > has about 760 250 (seven hundred sixty thousand+) decimal digits. > This makes the product > > rr = (of40)*(r^3041) > > to have more than 3 000 000 (three million+) decimal digits. > > I tried to compile it three times, twice unsuccessful > (insufficient amount of memory during compilation), > and the third time successful, after 12 hours work by > the compiler, and me increasing the paging file to > initial size 49152 Mb, max size 196608 Mb. > (At the end of compilation the Paging file reported as: > Recommended 24574 Mb, Currently allocated: 163765 Mb.) > I run a Hewlett-Packard HPE 500y, upgraded to 16 Gb RAM, > Windows 7, AMD Phenom(tm) II X6 1045T Processor 2.70 GHz (6 core). > The compiler produced a big exe file: > 09/27/2014 09:38 PM 20,602,960 void.exe > When I tried to run the exe file I got the error messages > as already enclosed at the beginning of this description. > Most of the time during compilation the computer used > all of the available memory. > > Note that I gave the options -rtsopts to the compiler, > and the option +RTS -K400M -RTS when I tried > to execute the compiled program (I believe this is > some kind of a request for more memory), and one more > attempt with +RTS -K40000M -RTS, both versions generated > the error messages shown above. > > P.S. Thanks to Richard Eisenberg and Herbert Valerio Riedel > for replying to my email, after BotScout kept me from > submitting my report. Apparently I passed the > evaluation-captcha (on my second attempt) but > nevertheless BotScout insisted I was spam. New description: Here is the error message first, followed by my description of what happened. {{{ hs> ghc -o void void.hs -rtsopts [1 of 1] Compiling Main ( void.hs, void.o ) Linking void.exe ... hs> void +RTS -K400M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug hs> void +RTS -K40000M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Description of what happened: I gave my program really large numbers. It contains the following line: {{{#!hs rr = (of40)*(r^3041) }}} where `of40` is an integer which has about `2 515 968` (that is two million+) decimal digits (explicitly written out and initialized in the .hs file). In addition, `of40` is multiplied by `r^3041`, where `r` is a 250-digit number so `r^3041` has about `760 250` (seven hundred sixty thousand+) decimal digits. This makes the product {{{#!hs rr = (of40)*(r^3041) }}} have more than `3 000 000` (three million+) decimal digits. I tried to compile it three times, twice unsuccessful (insufficient amount of memory during compilation), and the third time successful, after 12 hours work by the compiler, and me increasing the paging file to initial size 49152 Mb, max size 196608 Mb. (At the end of compilation the Paging file reported as: Recommended 24574 Mb, Currently allocated: 163765 Mb.) I run a Hewlett-Packard HPE 500y, upgraded to 16 Gb RAM, Windows 7, AMD Phenom(tm) II X6 1045T Processor 2.70 GHz (6 core). The compiler produced a big exe file: 09/27/2014 09:38 PM 20,602,960 void.exe When I tried to run the exe file I got the error messages as already enclosed at the beginning of this description. Most of the time during compilation the computer used all of the available memory. Note that I gave the options -rtsopts to the compiler, and the option +RTS -K400M -RTS when I tried to execute the compiled program (I believe this is some kind of a request for more memory), and one more attempt with +RTS -K40000M -RTS, both versions generated the error messages shown above. P.S. Thanks to Richard Eisenberg and Herbert Valerio Riedel for replying to my email, after BotScout kept me from submitting my report. Apparently I passed the evaluation-captcha (on my second attempt) but nevertheless BotScout insisted I was spam. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 19:58:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 19:58:04 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.d47f24a0838495f874ba13b2d93d8276@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: komadori Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3390 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * cc: gintas (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 20:10:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 20:10:42 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.27e421493b52e31d3b00eeb018fec6e0@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Build | Version: 7.7 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * architecture: arm => Unknown/Multiple Comment: I reproduced the error that bernalex mentioned using the steps from comment:22 and the patch from comment:24, using the 7.8.1 source code. Adding '-fno-warn-amp' to GhcLibHcsOpt made the problem go away. Since the problem does not occur with master, supposedly since Applicative is now a superclass of Monad, I am closing this ticket as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 20:46:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 20:46:40 -0000 Subject: [GHC] #4880: Functor, Monad, Applicative instances for Data.Monoid.First, Data.Monoid.Last In-Reply-To: <043.40e973f46a003a38ecb9f13d0d37e07c@haskell.org> References: <043.40e973f46a003a38ecb9f13d0d37e07c@haskell.org> Message-ID: <058.0f8e682068935dd20e098ae436a8b5aa@haskell.org> #4880: Functor, Monad, Applicative instances for Data.Monoid.First, Data.Monoid.Last -------------------------------------+------------------------------------- Reporter: sclv | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.0.1 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nicolast): For reference: merged through https://phabricator.haskell.org/D81 into 9a7440c0dc038a19432e86923ac30ade7bcea3e7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 20:54:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 20:54:58 -0000 Subject: [GHC] #4880: Functor, Monad, Applicative instances for Data.Monoid.First, Data.Monoid.Last In-Reply-To: <043.40e973f46a003a38ecb9f13d0d37e07c@haskell.org> References: <043.40e973f46a003a38ecb9f13d0d37e07c@haskell.org> Message-ID: <058.3f988abc6f97303c89ec30425f2c4825@haskell.org> #4880: Functor, Monad, Applicative instances for Data.Monoid.First, Data.Monoid.Last -------------------------------------+------------------------------------- Reporter: sclv | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.0.1 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 21:03:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 21:03:30 -0000 Subject: [GHC] #9646: Strange performance bug In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.1e73f4be38c752cdec6958feb03f7739@haskell.org> #9646: Strange performance bug -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by erikd): * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86_64 (amd64) Comment: @jstolarek : It looks you you do not have the criterion library installed. @dferuer : * Changing the order of the benchmarks makes no difference, the New3* runs still exhibit the same behaviour. * The `make` program is not a factor. I can take the commands printed using `make -n` and put them in a shell script for the same result. * Running the benchmarking program separately from the compile process gives almost identical results. I've also assured myself that the ghc command: {{{ ghc -Wall -Werror -fwarn-tabs -fPIC -ddump-to-file -ddump-prep -ddump-cmm -ddump-opt-cmm -ddump-stg -ddump-asm -O3 -XCPP -XMagicHash -XUnboxedTuples -XUnliftedFFITypes --make bench-integer.hs -o bench-integer }}} is the same in both cases. This is to be expected as `make` really just calls this `ghc --make` command. Behaviour is also the same with `-O2` and `-O1`. I tried compiling with `-O0` which gave radically different results but there were no interesting conclusions to be drawn. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 22:01:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 22:01:39 -0000 Subject: [GHC] #5190: TinyCoreLinux extension In-Reply-To: <055.a1f94ee83d72b7bafeac7dfd8c442650@haskell.org> References: <055.a1f94ee83d72b7bafeac7dfd8c442650@haskell.org> Message-ID: <070.ff8b164d4605c30cf5a41e6970e80109@haskell.org> #5190: TinyCoreLinux extension -------------------------------------+------------------------------------- Reporter: | Owner: josemaria.alkala | Status: closed Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.0.3 Component: Build | Keywords: System | Architecture: x86 Resolution: fixed | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: Installing | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thank you for your bug report. This was most likely fixed in 2043afcb0b938bc89257ab64d72a75b44a475c82 (2011). {{{ Avoid using iconv for the locale TextEncoding if we can help it }}} Check also this script for an attempt to install the haskell-platform on TinyCoreLinux: https://github.com/leonardoce/tinycore-ports/blob/master/haskell- platform/compile.sh Feel free to reopen this ticket it you're still having difficulties. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 29 23:05:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Sep 2014 23:05:28 -0000 Subject: [GHC] #9616: Incorrect numbers from HpcMarkup.markup_plugin In-Reply-To: <045.62543f73d6d6d97fee65adbd6d383235@haskell.org> References: <045.62543f73d6d6d97fee65adbd6d383235@haskell.org> Message-ID: <060.141e9a1a55db848ec5d42e637bcd6982@haskell.org> #9616: Incorrect numbers from HpcMarkup.markup_plugin -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Code | Version: 7.9 Coverage | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): D259 uploaded to Phabricator and awaiting review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 01:12:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 01:12:56 -0000 Subject: [GHC] #9649: symbols should/might be type level lists of chars In-Reply-To: <045.7eed415602713344419f19bba35ae3f7@haskell.org> References: <045.7eed415602713344419f19bba35ae3f7@haskell.org> Message-ID: <060.361eca07b8b45c2592fae64c3426d255@haskell.org> #9649: symbols should/might be type level lists of chars -------------------------------------+------------------------------------- Reporter: ibotty | Owner: ibotty Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree in that I find the impedance mismatch between term-level `String`s and type-level `Symbol`s a little annoying. But, there's a fairly sensible workaround: use lists of one-character symbols. A little quasi-quoting to ease the syntactic pain and you can get fairly far. I would still rather, of course, built-in support. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 03:19:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 03:19:14 -0000 Subject: [GHC] #9650: Unsatisfiable default signature Message-ID: <047.a4b8be6e7cb75fc07c5e7df2abc48bfd@haskell.org> #9650: Unsatisfiable default signature -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | accepts invalid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I discovered the `-XDefaultSignatures` extension and promptly wrote a default method that I feel should be rejected by the compiler: {{{#!hs {-# LANGUAGE DefaultSignatures #-} module Foo where class Foo a where foo :: proxy a -> b -> Int default foo :: (Integral b) => proxy a -> b -> Int foo _ b = fromIntegral b }}} GHC accepts this code, but rejects the instance `instance Foo Bool` because `No instance for (Integral b) arising from a use of ?Foo.$gdmfoo?`. It seems to me that the class should have never compiled in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 06:01:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 06:01:27 -0000 Subject: [GHC] #9646: Strange performance bug In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.a8a10f77e1ef2f15d1faf827490d3478@haskell.org> #9646: Strange performance bug -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:3 erikd]: > @jstolarek : It looks you you do not have the criterion library installed. I have `criterion-1.0.1.0` installed in a cabal sandbox. Perhaps your make script does not recognize sandboxes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 09:04:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 09:04:03 -0000 Subject: [GHC] #9650: Unsatisfiable default signature In-Reply-To: <047.a4b8be6e7cb75fc07c5e7df2abc48bfd@haskell.org> References: <047.a4b8be6e7cb75fc07c5e7df2abc48bfd@haskell.org> Message-ID: <062.4f6dfe1d22d66212fb444ad4b32dcfd1@haskell.org> #9650: Unsatisfiable default signature -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: dreixel (added) Comment: You point is, I think, that constraints that constrain ''only'' `b` (in this example) cannot possibly be satisfied at the usage site. If you wrote {{{ class Foo a where foo :: ...blah.. default foo :: forall b. (C a b) => ...blah... foo = ... }}} then a suitable instance for `C` (e.g. `instance C Int b`) might allow the `C a b` constraint to be satisfied at the `instance` declaration. However, nothing stops you writing {{{ instance Integral b where ... }}} and now the constraint would be satisfied. You may say this is silly, but people do write instance declarations like this (often `OVERLAPPABLE`). So I think the most we could do would be to warn that the default signature looks fishy. And then people would want a way to suppress the warning.... In short, there is merit in what you say, but I don't see an obvious way to take advantage of your observation. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 10:03:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 10:03:22 -0000 Subject: [GHC] #9650: Unsatisfiable default signature In-Reply-To: <047.a4b8be6e7cb75fc07c5e7df2abc48bfd@haskell.org> References: <047.a4b8be6e7cb75fc07c5e7df2abc48bfd@haskell.org> Message-ID: <062.a1b1358a20f743299e3b2968be38dcda@haskell.org> #9650: Unsatisfiable default signature -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): I think there will always be examples of unsatisfiable defaults, and GHC can't, in general, spot them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 10:07:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 10:07:09 -0000 Subject: [GHC] #9646: Strange performance bug In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.dd3787ea66e8856349e9ef461ea08c39@haskell.org> #9646: Strange performance bug -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by erikd): @jstolarek : No, my Makefile does not recognize cabal sandboxes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 10:11:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 10:11:23 -0000 Subject: [GHC] #7367: float-out causes extra allocation (was: Optimiser / Linker Problem on amd64) In-Reply-To: <045.fec15abb73687c53fcbc974d115b141d@haskell.org> References: <045.fec15abb73687c53fcbc974d115b141d@haskell.org> Message-ID: <060.a72992afb58a5db43dc7d3a3a2d3f860@haskell.org> #7367: float-out causes extra allocation -------------------------------------+------------------------------------- Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Build System => Compiler Comment: Summary copied from: https://ghc.haskell.org/trac/ghc/wiki/Status/SLPJ-Tickets -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 10:13:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 10:13:13 -0000 Subject: [GHC] #7152: Add flag to configure that skips overwriting of symlinks on install In-Reply-To: <044.af90b81c38ba7c31604bedf0b5844194@haskell.org> References: <044.af90b81c38ba7c31604bedf0b5844194@haskell.org> Message-ID: <059.a89f8f74258922725f8b26b5e8f7e496@haskell.org> #7152: Add flag to configure that skips overwriting of symlinks on install -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 10:44:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 10:44:04 -0000 Subject: [GHC] #9646: Strange performance bug In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.6c0fa13db17ec0a19daaeacb7521ffbb@haskell.org> #9646: Strange performance bug -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by erikd): I added a a number of -ddump-* flags and reduced the `New3/GHC/InteterNatural.hs` file to contain nothing but the `timeNatural` function that we're interested in. What I found was: * Desugar stage output (file Natural.dump-ds) output is identical. * Simplifier stage ( (file Natural.dump-simpl) is different. I've added the fast and slow versions of the .dump-simpl outputs. The slow version of the code seems to have a lot more let bindings that the fast version. The fast version is more like to use case expressions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 11:13:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 11:13:19 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.83fb6d083b5107ec745ccb9c96176256@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): I'd just like to ask where this ticket stands after the patch. Does it solve simonmar's (1), namely produced package IDs? If we build with this patch *without* parallel builds, does this mean we should now get deterministic package ID and anything else is a bug, or are there still known cases that produce different IDs? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 13:24:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 13:24:59 -0000 Subject: [GHC] #7068: Extensive Memory usage (regression) In-Reply-To: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> References: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> Message-ID: <063.53f19a879abdabeb836ec704ac2b7676@haskell.org> #7068: Extensive Memory usage (regression) -------------------------------------+------------------------------------- Reporter: waldheinz | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: infoneeded => closed * resolution: => fixed Comment: I remember I fiddled with this but couldn't get it to compile after a short time; but I do believe this behavior has been fixed (re: many other very similar tickets: #8852, #8980, #8941, #8960, #7898, #5550, #8836). Please re-open if you think otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 13:33:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 13:33:54 -0000 Subject: [GHC] #9650: Unsatisfiable default signature In-Reply-To: <047.a4b8be6e7cb75fc07c5e7df2abc48bfd@haskell.org> References: <047.a4b8be6e7cb75fc07c5e7df2abc48bfd@haskell.org> Message-ID: <062.b876b1d5778ae6fb4d23bf57893bf00c@haskell.org> #9650: Unsatisfiable default signature -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by crockeea): * status: new => closed * resolution: => invalid Comment: I see Simon's point, so I suppose there's nothing to be done here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 14:21:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 14:21:37 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.5b27ccfeb6d4ecd4264561c238742c4e@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): No, there are still several problems that remain before (1) is solved. See the description of the ticket for a (possibly incomplete) list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 14:23:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 14:23:16 -0000 Subject: [GHC] #781: GHCi on x86_64, cannot link to static data in shared libs In-Reply-To: <044.a73c522b97030f99c5fa39d521657f06@haskell.org> References: <044.a73c522b97030f99c5fa39d521657f06@haskell.org> Message-ID: <059.f93fe79651e6c5e19573f5e54d3fc93a@haskell.org> #781: GHCi on x86_64, cannot link to static data in shared libs -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 6.5 Resolution: | Keywords: getEnvironment Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: getEnvironment01 | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: closed => new * resolution: fixed => Comment: Works in 7.8.3 because we're using dynamic linking. The bug still remains in the RTS linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 15:41:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 15:41:12 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.09be0237eb18a1268f4793638608a554@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: | Version: 7.9 libraries/haskell2010 | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): Ack! Now I see what you mean. `Applicative` not even being in the package _is_ a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 17:04:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 17:04:23 -0000 Subject: [GHC] #9046: Panic in GHCi when using :print In-Reply-To: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> References: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> Message-ID: <060.d62d9d1a092617178786a91ca81b07ca@haskell.org> #9046: Panic in GHCi when using :print -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: tests/ghci.debugger/scripts/print036| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by francesquini): Same problem, different steps: {{{ GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> let x = 3 + 4 Prelude> :print x x = (_t1::Num a => a) Prelude> :force x x = _ Prelude> print _t1 ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): tcTyVarDetails a{tv atm} [tv] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 18:47:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 18:47:37 -0000 Subject: [GHC] #9046: Panic in GHCi when using :print In-Reply-To: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> References: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> Message-ID: <060.bc05684c2788eb93e5299ca244b93124@haskell.org> #9046: Panic in GHCi when using :print -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: tests/ghci.debugger/scripts/print036| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): This is clearly a bug. (All panics are, really.) And hence embarrassing to have open for so long. But I didn't write the code for the GHCi debugger, and I only partly understand it. It needs love and care from someone. At the moment this ticket is sitting in my "look at this when I have time" pile, but I never have time. It would be great if someone was willing to take the time to dig into how the debugger works, and maybe "own" it for the future. The good thing is that it's only one or two modules, and there are few non-local ramifications, so it's a well-contained collection of issues. Also, this ticket a show-stopper for anyone? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 19:58:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 19:58:41 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.65015662ad3837091f1616e1e305d5f1@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm sorry, I'm quite confused. GHC already has a `-fwarn-tabs` flag, doesn't it? There are two patches offered above, but I'm not clear what the purpose of either is. Maybe I have not ready through this ticket carefully enough. Would someone just like to write down what the issue is, what the alternatives are, their pros and cons, and which of the alternatives they recommend following. I have no opinion myself; I'd just like see this resolved. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 20:04:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 20:04:18 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.c10c259be70a34d1f668c34006a1a2cf@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): For what it's worth, I don't have a strong opinion either way. I think we are agreed that: * In an user-written type signature, * if an application of a closed type family is "apart" from all equations of the family, * then we should signal either an error or a warning. Lennart says "error", Richard says "warning", and I can't work up much excitement about which is chosen. One advantage of "error" is that you don't have to add a flag to suppress the warning! Anyway, if someone wants to implement it, go ahead! This all applies to ''user-written type signatures''. I don't want to apply this to "types that appear during the type inference process" because I don't know exactly what that might mean. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 20:50:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 20:50:44 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.8baebaa92a9e07f3cf5220d0a8f5226b@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by augustss): I would like it to apply to types that appear during type checking, because I think it's an error and errors should be reported. I presume that at some point during type checking the closed type family equations are used to simplify a type. If at that point you discover that none of the equations can possibly match, then that should be reported as an error. If irreducible closed type family (type) expressions are allowed then these are some kind of "ghost types". If we agree that that only "data" and "newtype" generate types, then these ghosts are some new kind of types that have no meaning. They are not empty types, they simply malformed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 20:55:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 20:55:57 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.386401d07303c385c15a4e913af19892@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: | Version: 7.9 libraries/haskell2010 | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by singpolyma): > Or is it users who don't want to let a GHC monoculture set the standard and would prefer to work with a smaller subset of the language, but still want to have access to the ecosystem of packages through cabal? Folks who may have other compilers in mind, who would prefer to implement against a standard or at least have the ability to have their code compile against a compiler that implements the standard. This is me. My primary use of the haskell2010 package is to test my code against it, as well as base, in order to check that it is more likely to work on a standards-conformant Haskell implementation. To that end, I would prefer it if haskell2010 were basically just cut-n-paste the code from the report and be done with it. This would mean a different Monad instance, which I gather might cause some complexity for `do` notation (though will it really? GHC already has rebindable do, it seems like this would just be a special case of that). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 21:03:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 21:03:32 -0000 Subject: [GHC] #9651: Increasing verbosity doesn't give useful information for why we couldn't load package Message-ID: <045.68c944ad4897c3941e1006351a1a6eae@haskell.org> #9651: Increasing verbosity doesn't give useful information for why we couldn't load package -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I don't time to fix this now, so recording so I remember. {{{ [ezyang at hs01 ghc-nocode]$ /home/hs01/ezyang/ghc-head/inplace/bin/ghc- stage2 -package-key ghc_GE0xPzNsQzT2p10hpwDwSW --interactive -package-db libraries/bootstrapping.conf -v GHCi, version 7.9.20140929: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.9.20140929, stage 2 booted by GHC version 7.8.3 Using binary package database: /home/hs01/ezyang/ghc- head/inplace/lib/package.conf.d/package.cache Using binary package database: libraries/bootstrapping.conf/package.cache *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: : cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW (use -v for more information) [ezyang at hs01 ghc-nocode]$ /home/hs01/ezyang/ghc-head/inplace/bin/ghc- stage2 -package-key ghc_GE0xPzNsQzT2p10hpwDwSW --interactive -package-db libraries/bootstrapping.conf GHCi, version 7.9.20140929: http://www.haskell.org/ghc/ :? for help : cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW (use -v for more information) [ezyang at hs01 ghc-nocode]$ /home/hs01/ezyang/ghc-head/inplace/bin/ghc- stage2 -package-key ghc_GE0xPzNsQzT2p10hpwDwSW --interactive -package-db libraries/bootstrapping.conf -v GHCi, version 7.9.20140929: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.9.20140929, stage 2 booted by GHC version 7.8.3 Using binary package database: /home/hs01/ezyang/ghc- head/inplace/lib/package.conf.d/package.cache Using binary package database: libraries/bootstrapping.conf/package.cache *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: : cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW (use -v for more information) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 21:06:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 21:06:10 -0000 Subject: [GHC] #9652: Bootstrapping GHC HEAD against itself doesn't work Message-ID: <045.174cce8060d844f9c120636e662de792@haskell.org> #9652: Bootstrapping GHC HEAD against itself doesn't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've got a partial patch: {{{ diff --git a/ghc.mk b/ghc.mk index eedb023..37ef2f2 100644 --- a/ghc.mk +++ b/ghc.mk @@ -719,7 +719,7 @@ ifneq "$(BINDIST)" "YES" ifneq "$(BOOTSTRAPPING_CONF)" "" ifeq "$(wildcard $(BOOTSTRAPPING_CONF))" "" -$(shell echo "[]" >$(BOOTSTRAPPING_CONF)) +$(shell $(GHC_PKG) init $(BOOTSTRAPPING_CONF)) endif endif }}} But I'm dying here: {{{ ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No such file or directory compiler/ghc.mk:646: compiler/stage1/build/.depend-v.haskell: No such file or directory ghc/ghc.mk:114: ghc/stage1/build/.depend.haskell: No such file or directory "rm" -f ghc/stage1/build/.depend.haskell.tmp "/home/hs01/ezyang/ghc-head/inplace/bin/ghc-stage2" -M -static -H32m -O -package-db libraries/bootstrapping.conf -hide-all-packages -i -ighc/. -ighc/stage1/build -ighc/stage1/build/autogen -Ighc/stage1/build -Ighc/stage1/build/autogen -optP-include -optPghc/stage1/build/autogen/cabal_macros.h -package-key array_GX4NwjS8xZkC2ZPtjgwhnz -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv -package-key direc_1OR7Bu5EIqqJUPTpfzOCIt -package-key filep_34DFDFT9FVD9pRLLgh8IdQ -package-key ghc_GE0xPzNsQzT2p10hpwDwSW -package-key proce_JJ2k66FcGHSLNmYZUkX8Td -package-key unix_4dEexQFispVG782agZacZC -Wall -XHaskell2010 -no-user-package-db -rtsopts -odir ghc/stage1/build -hidir ghc/stage1/build -stubdir ghc/stage1/build -dep- makefile ghc/stage1/build/.depend.haskell.tmp -dep-suffix "" -include-pkg- deps ghc/./Main.hs : cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW (use -v for more information) ghc/ghc.mk:114: recipe for target 'ghc/stage1/build/.depend.haskell' failed make[1]: *** [ghc/stage1/build/.depend.haskell] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 }}} A bit hard to diagnose due to #9651. Recording this so I don't forget. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 21:42:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 21:42:41 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.3fd8cd8fc85d2940993d57382c05e440@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:16 simonpj]: > I'm sorry, I'm quite confused. GHC already has a `-fwarn-tabs` flag, doesn't it? There are two patches offered above, but I'm not clear what the purpose of either is. Maybe I have not ready through this ticket carefully enough. I don't understand that either. The essential ''problem'' we have is that we want `-fwarn-tabs` to be the default, but we have to find some way to get validation to pass when there are currently a lot of libraries in the GHC tree that have tabs but don't invoke `-fno-warn-tabs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 21:47:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 21:47:35 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.eab099bec5a73dd112ebf03fc78b6be6@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thoughtpolice): The above patch does all of the above correctly; it is also on Phabricator - see Phab:D255 (which also built correctly). In essence it just adds `Opt_WarnTabs` (AKA `-fwarn-tabs`) to `standardWarnings` in `DynFlags`, which is the correct move. Next, it disables `-fno-warn-tabs` when building the libraries by modifying `mk /validate-settings.mk` to include `-fno-warn-tabs`, so that everything can validate correctly. I need to do a review on the testsuite changes in the patch, but it seems fine at a quick glance (I mostly wonder about the changes to the testsuite driver). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 21:48:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 21:48:21 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.4875fab5f08d8766f96a15c504821f04@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D255 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D255 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 23:01:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 23:01:58 -0000 Subject: [GHC] #9653: globalRegMaybe not defined for qnx-nto-arm Message-ID: <049.4cb51187e6a3307b09605a003ec0d9a0@haskell.org> #9653: globalRegMaybe not defined for qnx-nto-arm -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: QNX Architecture: arm | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm having trouble figuring out what I do to add support. I'm getting this when building my qnx-nto-arm cross-compiler on head: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140929 for arm-unknown-nto-qnx): globalRegMaybe not defined for this platform -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 23:14:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 23:14:52 -0000 Subject: [GHC] #9653: globalRegMaybe not defined for qnx-nto-arm In-Reply-To: <049.4cb51187e6a3307b09605a003ec0d9a0@haskell.org> References: <049.4cb51187e6a3307b09605a003ec0d9a0@haskell.org> Message-ID: <064.6386e06298ce5894e42470a2cf06666c@haskell.org> #9653: globalRegMaybe not defined for qnx-nto-arm ----------------------------------------------+--------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: QNX | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by singpolyma): includes/stg/MachRegs.h contains information for arm, and compiler/codeGen/CodeGen/Platform/ARM.hs says to use it, but includes/CodeGen.Platform.hs does not mention MACHREGS_arm anywhere, and does not have the register-name-to-indices #defines present. I'm not sure what the index values are supposed to be in this case, so I'm not sure how to proceed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 23:20:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 23:20:23 -0000 Subject: [GHC] #9653: globalRegMaybe not defined for qnx-nto-arm In-Reply-To: <049.4cb51187e6a3307b09605a003ec0d9a0@haskell.org> References: <049.4cb51187e6a3307b09605a003ec0d9a0@haskell.org> Message-ID: <064.48c6464b671e600310b3ba8ebcd4f4ad@haskell.org> #9653: globalRegMaybe not defined for qnx-nto-arm ----------------------------------------------+--------------------------- Reporter: singpolyma | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: QNX | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 9593 Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by singpolyma): * status: new => closed * resolution: => duplicate * related: => 9593 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 30 23:20:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Sep 2014 23:20:35 -0000 Subject: [GHC] #9653: globalRegMaybe not defined for qnx-nto-arm In-Reply-To: <049.4cb51187e6a3307b09605a003ec0d9a0@haskell.org> References: <049.4cb51187e6a3307b09605a003ec0d9a0@haskell.org> Message-ID: <064.5dc9587cd29022cda2dbaeb1f5e17b11@haskell.org> #9653: globalRegMaybe not defined for qnx-nto-arm ----------------------------------------------+--------------------------- Reporter: singpolyma | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: QNX | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9593 Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by singpolyma): * related: 9593 => #9593 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 2 12:46:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Sep 2014 12:46:30 -0000 Subject: [GHC] #9541: ghc: panic, "RegAlloc.Liveness.computeLivenss; SCCs aren't in reverse dependent order" Message-ID: <046.68efa89057831cb9c8ddc6a98623ef69@haskell.org> #9541: ghc: panic, "RegAlloc.Liveness.computeLivenss; SCCs aren't in reverse dependent order" -------------------------------------+------------------------------------- Reporter: aleator | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When porting older code to work on ghc-7.8.2 I get a ghc panic with the following error. {{{ > uname -a Linux fupu2 3.13.0-34-generic #60-Ubuntu SMP Wed Aug 13 15:45:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > ghc --make -O2 BooleansExercise.hs [3 of 3] Compiling Main ( BooleansExercise.hs, BooleansExercise.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package old-time-1.1.0.2 ... linking ... done. Loading package text-1.1.1.3 ... linking ... done. Loading package polyparse-1.9 ... linking ... done. Loading package cpphs-1.18.5 ... linking ... done. Loading package haskell-src-exts-1.15.0.1 ... linking ... done. Loading package syb-0.4.2 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package th-lift-0.6.1 ... linking ... done. Loading package th-orphans-0.8.1 ... linking ... done. Loading package haskell-src-meta-0.6.0.7 ... linking ... done. Loading package Interpolation-0.3.0 ... linking ... done. ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): RegAlloc.Liveness.computeLivenss SCCs aren't in reverse dependent order bad blockId cVmY [NONREC cVyv: movq $64,904(%r13) jmp stg_gc_unpt_r1, NONREC cVyr: movq $40,904(%r13) movq $block{v cUIX}_info,(%rbp) movq %vI_sRYu,%rbx jmp stg_gc_unbx_r1, NONREC cVyq: movq $48,904(%r13) jmp stg_gc_unpt_r1, NONREC cVqw: movq $main:Main.S{d riit}_con_info,-40(%r12) movq %vI_sRYx,-32(%r12) movq %vI_sS14,-24(%r12) leaq -39(%r12),%vI_cV0M addq $-24,%r12 movq $block{v cV0N}_info,-16(%rbp) movq %vI_sRPm,%rdi movq %vI_cV0M,%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS14,-8(%rbp) movq %vI_sRYx,(%rbp) addq $-16,%rbp jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVtO: movq $24,904(%r13) movq $block{v cVjC}_info,-24(%rbp) movq %vI_sS2p,-16(%rbp) movq %vI_sS2q,-8(%rbp) movq %vI_sRYx,(%rbp) movq %vI_cUU2,32(%rbp) addq $-24,%rbp jmp stg_gc_noregs, NONREC cVsT: addq $-24,%r12 movq %vI_sS2q,%r14 movq %vI_cUU2,%rbx addq $40,%rbp jmp go9{v sS2o}_info, NONREC cVsS: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS2P,(%r12) movq $block{v cVl0}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS2P,8(%rbp) movq %vI_sS2q,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUU2,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVsM: cmpq $8,%vI_sS2P jge _cVsT jmp _cVsS, NONREC cVsG: movq %vI_sRPo,%vI_sS2P addq %vI_sS2p,%vI_sS2P testq %vI_sS2P,%vI_sS2P jl _cVsT jmp _cVsM, NONREC cVsA: cmpq $8,%vI_sRYx jge _cVsT jmp _cVsG, NONREC cVsu: testq %vI_sRYx,%vI_sRYx jl _cVsT jmp _cVsA, NONREC cVsm: cmpq %vI_sS2p,%vI_sRYv je _cVsT jmp _cVsu, NONREC cVtz: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS2A,(%r12) movq $block{v cVkk}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS2A,8(%rbp) movq %vI_sS2q,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUU2,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVtt: cmpq $8,%vI_sS2A jge _cVsT jmp _cVtz, NONREC cVtn: movq %vI_sRPo,%vI_sS2A addq %vI_sS2p,%vI_sS2A testq %vI_sS2A,%vI_sS2A jl _cVsT jmp _cVtt, NONREC cVth: cmpq $8,%vI_sRYx jge _cVsT jmp _cVtn, NONREC cVtb: testq %vI_sRYx,%vI_sRYx jl _cVsT jmp _cVth, NONREC cVsn: movq %vI_sS2p,%vI_nWsA negq %vI_nWsA cmpq %vI_nWsA,%vI_sRYv je _cVsT jmp _cVtb, NONREC cVsp: testq %vI_sS2p,%vI_sS2p jge _cVsm jmp _cVsn, NONREC cVjB: addq $24,%r12 cmpq 856(%r13),%r12 ja _cVtO jmp _cVsp, NONREC cVqx: movq $go9{v sS2o}_info,-40(%r12) movq %vI_sRPm,-32(%r12) movq %vI_cUIw,-24(%r12) movq %vI_sRPo,-16(%r12) movq %vI_sRYv,-8(%r12) movq %vI_sRYx,(%r12) leaq -39(%r12),%vI_cUU2 movl $a4{v rRvU}_closure+2,%vI_sS2q movq $-1,%vI_sS2p jmp _cVjB, NONREC cVqq: cmpq $8,%vI_sS14 jl _cVqw jmp _cVqx, NONREC cVvl: movq $24,904(%r13) movq $block{v cVi4}_info,-24(%rbp) movq %vI_sS19,-16(%rbp) movq %vI_sS1a,-8(%rbp) movq %vI_sRYx,(%rbp) movq %vI_cUQr,32(%rbp) addq $-24,%rbp jmp stg_gc_noregs, NONREC cVuq: addq $-24,%r12 movq %vI_sS1a,%r14 movq %vI_cUQr,%rbx addq $40,%rbp jmp go9{v sS18}_info, NONREC cVup: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS1z,(%r12) movq $block{v cVjs}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS1z,8(%rbp) movq %vI_sS1a,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUQr,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVuj: cmpq $8,%vI_sS1z jge _cVuq jmp _cVup, NONREC cVud: movq %vI_sRPo,%vI_sS1z addq %vI_sS19,%vI_sS1z testq %vI_sS1z,%vI_sS1z jl _cVuq jmp _cVuj, NONREC cVu7: cmpq $8,%vI_sRYx jge _cVuq jmp _cVud, NONREC cVu1: testq %vI_sRYx,%vI_sRYx jl _cVuq jmp _cVu7, NONREC cVtT: cmpq %vI_sS19,%vI_sRYv je _cVuq jmp _cVu1, NONREC cVv6: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS1k,(%r12) movq $block{v cViM}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS1k,8(%rbp) movq %vI_sS1a,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUQr,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVv0: cmpq $8,%vI_sS1k jge _cVuq jmp _cVv6, NONREC cVuU: movq %vI_sRPo,%vI_sS1k addq %vI_sS19,%vI_sS1k testq %vI_sS1k,%vI_sS1k jl _cVuq jmp _cVv0, NONREC cVuO: cmpq $8,%vI_sRYx jge _cVuq jmp _cVuU, NONREC cVuI: testq %vI_sRYx,%vI_sRYx jl _cVuq jmp _cVuO, NONREC cVtU: movq %vI_sS19,%vI_nWsL negq %vI_nWsL cmpq %vI_nWsL,%vI_sRYv je _cVuq jmp _cVuI, NONREC cVtW: testq %vI_sS19,%vI_sS19 jge _cVtT jmp _cVtU, NONREC cVi3: addq $24,%r12 cmpq 856(%r13),%r12 ja _cVvl jmp _cVtW, NONREC cVqr: movq $go9{v sS18}_info,-40(%r12) movq %vI_sRPm,-32(%r12) movq %vI_cUIw,-24(%r12) movq %vI_sRPo,-16(%r12) movq %vI_sRYv,-8(%r12) movq %vI_sRYx,(%r12) leaq -39(%r12),%vI_cUQr movl $a4{v rRvU}_closure+2,%vI_sS1a movq $-1,%vI_sS19 jmp _cVi3, NONREC cVqk: leaq 1(%vI_sRPo),%vI_sS14 testq %vI_sS14,%vI_sS14 jge _cVqq jmp _cVqr, NONREC cVwS: movq $24,904(%r13) movq $block{v cVgw}_info,-24(%rbp) movq %vI_sRZS,-16(%rbp) movq %vI_sRZT,-8(%rbp) movq %vI_sRYx,(%rbp) movq %vI_cUMN,32(%rbp) addq $-24,%rbp jmp stg_gc_noregs, NONREC cVvX: addq $-24,%r12 movq %vI_sRZT,%r14 movq %vI_cUMN,%rbx addq $40,%rbp jmp go9{v sRZR}_info, NONREC cVvW: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS0i,(%r12) movq $block{v cVhU}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS0i,8(%rbp) movq %vI_sRZT,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUMN,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVvQ: cmpq $8,%vI_sS0i jge _cVvX jmp _cVvW, NONREC cVvK: movq %vI_sRPo,%vI_sS0i addq %vI_sRZS,%vI_sS0i testq %vI_sS0i,%vI_sS0i jl _cVvX jmp _cVvQ, NONREC cVvE: cmpq $8,%vI_sRYx jge _cVvX jmp _cVvK, NONREC cVvy: testq %vI_sRYx,%vI_sRYx jl _cVvX jmp _cVvE, NONREC cVvq: cmpq %vI_sRZS,%vI_sRYv je _cVvX jmp _cVvy, NONREC cVwD: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS03,(%r12) movq $block{v cVhe}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS03,8(%rbp) movq %vI_sRZT,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUMN,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVwx: cmpq $8,%vI_sS03 jge _cVvX jmp _cVwD, NONREC cVwr: movq %vI_sRPo,%vI_sS03 addq %vI_sRZS,%vI_sS03 testq %vI_sS03,%vI_sS03 jl _cVvX jmp _cVwx, NONREC cVwl: cmpq $8,%vI_sRYx jge _cVvX jmp _cVwr, NONREC cVwf: testq %vI_sRYx,%vI_sRYx jl _cVvX jmp _cVwl, NONREC cVvr: movq %vI_sRZS,%vI_nWsW negq %vI_nWsW cmpq %vI_nWsW,%vI_sRYv je _cVvX jmp _cVwf, NONREC cVvt: testq %vI_sRZS,%vI_sRZS jge _cVvq jmp _cVvr, NONREC cVgv: addq $24,%r12 cmpq 856(%r13),%r12 ja _cVwS jmp _cVvt, NONREC cVql: movq $go9{v sRZR}_info,-40(%r12) movq %vI_sRPm,-32(%r12) movq %vI_cUIw,-24(%r12) movq %vI_sRPo,-16(%r12) movq %vI_sRYv,-8(%r12) movq %vI_sRYx,(%r12) leaq -39(%r12),%vI_cUMN movl $a4{v rRvU}_closure+2,%vI_sRZT movq $-1,%vI_sRZS jmp _cVgv, NONREC cVqc: cmpq $8,%vI_sRYx jl _cVqk jmp _cVql, NONREC cVyp: movq $24,904(%r13) movq $block{v cVeY}_info,-24(%rbp) movq %vI_sRYC,-16(%rbp) movq %vI_sRYD,-8(%rbp) movq %vI_sRYx,(%rbp) movq %vI_cUJc,32(%rbp) addq $-24,%rbp jmp stg_gc_noregs, NONREC cVxu: addq $-24,%r12 movq %vI_sRYD,%r14 movq %vI_cUJc,%rbx addq $40,%rbp jmp go9{v sRYB}_info, NONREC cVxt: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sRZ2,(%r12) movq $block{v cVgm}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sRZ2,8(%rbp) movq %vI_sRYD,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUJc,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVxn: cmpq $8,%vI_sRZ2 jge _cVxu jmp _cVxt, NONREC cVxh: movq %vI_sRPo,%vI_sRZ2 addq %vI_sRYC,%vI_sRZ2 testq %vI_sRZ2,%vI_sRZ2 jl _cVxu jmp _cVxn, NONREC cVxb: cmpq $8,%vI_sRYx jge _cVxu jmp _cVxh, NONREC cVx5: testq %vI_sRYx,%vI_sRYx jl _cVxu jmp _cVxb, NONREC cVwX: cmpq %vI_sRYC,%vI_sRYv je _cVxu jmp _cVx5, NONREC cVya: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sRYN,(%r12) movq $block{v cVfG}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sRYN,8(%rbp) movq %vI_sRYD,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUJc,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVy4: cmpq $8,%vI_sRYN jge _cVxu jmp _cVya, NONREC cVxY: movq %vI_sRPo,%vI_sRYN addq %vI_sRYC,%vI_sRYN testq %vI_sRYN,%vI_sRYN jl _cVxu jmp _cVy4, NONREC cVxS: cmpq $8,%vI_sRYx jge _cVxu jmp _cVxY, NONREC cVxM: testq %vI_sRYx,%vI_sRYx jl _cVxu jmp _cVxS, NONREC cVwY: movq %vI_sRYC,%vI_nWt7 negq %vI_nWt7 cmpq %vI_nWt7,%vI_sRYv je _cVxu jmp _cVxM, NONREC cVx0: testq %vI_sRYC,%vI_sRYC jge _cVwX jmp _cVwY, NONREC cVeX: addq $24,%r12 cmpq 856(%r13),%r12 ja _cVyp jmp _cVx0, NONREC cVqd: movq $go9{v sRYB}_info,-40(%r12) movq %vI_sRPm,-32(%r12) movq %vI_cUIw,-24(%r12) movq %vI_sRPo,-16(%r12) movq %vI_sRYv,-8(%r12) movq %vI_sRYx,(%r12) leaq -39(%r12),%vI_cUJc movl $a4{v rRvU}_closure+2,%vI_sRYD movq $-1,%vI_sRYC jmp _cVeX, NONREC cVqf: movq 32(%rbp),%vI_cUIw movq 8(%rbp),%vI_sRPm movq 24(%rbp),%vI_sRPo movq 16(%rbp),%vI_sRYv movq 7(%rbx),%vI_sRYx testq %vI_sRYx,%vI_sRYx jge _cVqc jmp _cVqd, NONREC cUJ2: addq $48,%r12 cmpq 856(%r13),%r12 ja _cVyq jmp _cVqf, NONREC cUJ3: jmp *(%rbx), NONREC cVox: addq $-40,%r12 movq $block{v cUJ2}_info,(%rbp) movq %vI_cUIx,%rbx movq %vI_sRYu,16(%rbp) testq $7,%rbx jne _cUJ2 jmp _cUJ3, NONREC cVpd: movq %vI_sS6a,%r14 movq %vI_cVb9,%rbx addq $40,%rbp jmp go9{v sS68}_info, NONREC cVoE: movl $a4{v rRvU}_closure+2,%vI_sS6a jmp _cVpd, NONREC cVoy: movq $go9{v sS68}_info,-32(%r12) movq %vI_sRPm,-24(%r12) movq %vI_cUIw,-16(%r12) movq %vI_cUIx,-8(%r12) movq %vI_sRPo,(%r12) leaq -31(%r12),%vI_cVb9 jmp _cVoE, NONREC cVow: cmpq $1,%vI_sRYu jne _cVox jmp _cVoy, NONREC cUIY: addq $40,%r12 cmpq 856(%r13),%r12 ja _cVyr jmp _cVow, NONREC cVos: movq %vI_sRYs,%vI_sRYu jmp _cUIY, NONREC cVot: movq %vI_sRYs,%vI_sRYu negq %vI_sRYu jmp _cUIY, NONREC cUIQ: movq 32(%rbp),%vI_cUIw movq 16(%rbp),%vI_cUIx movq 8(%rbp),%vI_sRPm movq 24(%rbp),%vI_sRPo movq 7(%rbx),%vI_sRYs testq %vI_sRYs,%vI_sRYs jge _cVos jmp _cVot, NONREC cUIR: jmp *(%rbx), NONREC cVyu: movq 6(%rbx),%vI_sRYk movq 14(%rbx),%vI_sRYl movq $stg_ap_2_upd_info,-56(%r12) movq 32(%rbp),%vI_nWti movq %vI_nWti,-40(%r12) movq %vI_sRYl,-32(%r12) movq $lvl60{v sRYn}_info,-24(%r12) movq %vI_sRYk,-8(%r12) movq 16(%rbp),%vI_nWtj movq %vI_nWtj,(%r12) movq $block{v cUIQ}_info,(%rbp) movq %vI_sRYk,%rbx leaq -24(%r12),%vI_nWtk movq %vI_nWtk,16(%rbp) leaq -56(%r12),%vI_nWtl movq %vI_nWtl,32(%rbp) testq $7,%rbx jne _cUIQ jmp _cUIR, NONREC cVeS: addq $64,%r12 cmpq 856(%r13),%r12 ja _cVyv jmp _cVyu, NONREC cVeT: movl $ghc-prim:GHC.Types.[]{(w) d 6m}_closure+1,%ebx addq $40,%rbp jmp *(%rbp), NONREC cUIq: movq %rbx,%vI_nWrL andq $7,%vI_nWrL cmpq $2,%vI_nWrL jae _cVeS jmp _cVeT, NONREC cUIX: movq 32(%rbp),%vI_cUIw movq 16(%rbp),%vI_cUIx movq 8(%rbp),%vI_sRPm movq 24(%rbp),%vI_sRPo movq %rbx,%vI_sRYu jmp _cUIY, NONREC cVse: movq $48,904(%r13) jmp stg_gc_unpt_r1, NONREC cVsd: movq $24,904(%r13) movq $block{v cVlc}_info,-8(%rbp) movq %vI_sS4W,(%rbp) movq %vI_sS4V,8(%rbp) movq %vI_cV7D,48(%rbp) addq $-8,%rbp jmp stg_gc_noregs, NONREC cVri: addq $-24,%r12 movq %vI_sS4W,%r14 movq %vI_cV7D,%rbx addq $56,%rbp jmp go9{v sS4U}_info, NONREC cVrh: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS5l,(%r12) movq $block{v cVmA}_info,8(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS5l,32(%rbp) movq %vI_sS4W,40(%rbp) movq %vI_cV7D,48(%rbp) addq $8,%rbp jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVrb: cmpq $8,%vI_sS5l jge _cVri jmp _cVrh, NONREC cVr5: movq %vI_sRPo,%vI_sS5l addq %vI_sS4V,%vI_sS5l testq %vI_sS5l,%vI_sS5l jl _cVri jmp _cVrb, NONREC cVqZ: cmpq $8,%vI_sRYx jge _cVri jmp _cVr5, NONREC cVqT: testq %vI_sRYx,%vI_sRYx jl _cVri jmp _cVqZ, NONREC cVqL: cmpq %vI_sS4V,%vI_sRYv je _cVri jmp _cVqT, NONREC cVrY: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS56,(%r12) movq $block{v cVlU}_info,8(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS56,32(%rbp) movq %vI_sS4W,40(%rbp) movq %vI_cV7D,48(%rbp) addq $8,%rbp jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVrS: cmpq $8,%vI_sS56 jge _cVri jmp _cVrY, NONREC cVrM: movq %vI_sRPo,%vI_sS56 addq %vI_sS4V,%vI_sS56 testq %vI_sS56,%vI_sS56 jl _cVri jmp _cVrS, NONREC cVrG: cmpq $8,%vI_sRYx jge _cVri jmp _cVrM, NONREC cVrA: testq %vI_sRYx,%vI_sRYx jl _cVri jmp _cVrG, NONREC cVqM: movq %vI_sS4V,%vI_nWsm negq %vI_nWsm cmpq %vI_nWsm,%vI_sRYv je _cVri jmp _cVrA, NONREC cVqO: testq %vI_sS4V,%vI_sS4V jge _cVqL jmp _cVqM, NONREC cVlb: addq $24,%r12 cmpq 856(%r13),%r12 ja _cVsd jmp _cVqO, NONREC cVqG: movq $go9{v sS4U}_info,-40(%r12) movq %vI_sRPm,-32(%r12) movq %vI_cUIw,-24(%r12) movq %vI_sRPo,-16(%r12) movq %vI_sRYv,-8(%r12) movq %vI_sRYx,(%r12) leaq -39(%r12),%vI_cV7D movl $a4{v rRvU}_closure+2,%vI_sS4W movq $-1,%vI_sS4V jmp _cVlb, NONREC cVqD: addq $48,%r12 cmpq 856(%r13),%r12 ja _cVse jmp _cVqG, NONREC cVsh: movq $104,904(%r13) jmp stg_gc_unpt_r1, NONREC cVsg: movq $sat_sS4S{v}_info,-96(%r12) movq %vI_sRPm,-80(%r12) movq %vI_cUIw,-72(%r12) movq %vI_sRPo,-64(%r12) movq %vI_sRYv,-56(%r12) movq %vI_sRYx,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq %vI_sRYx,-32(%r12) movq 8(%rbp),%vI_nWsx movq %vI_nWsx,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsy movq %vI_nWsy,-8(%r12) leaq -96(%r12),%vI_nWsz movq %vI_nWsz,(%r12) leaq -14(%r12),%rbx addq $56,%rbp jmp *(%rbp), NONREC cVqE: addq $104,%r12 cmpq 856(%r13),%r12 ja _cVsh jmp _cVsg, NONREC cV0N: movq 48(%rbp),%vI_cUIw movq 24(%rbp),%vI_sRPm movq 40(%rbp),%vI_sRPo movq 32(%rbp),%vI_sRYv movq 16(%rbp),%vI_sRYx movq %rbx,%vI_nWrN andq $7,%vI_nWrN cmpq $2,%vI_nWrN jae _cVqD jmp _cVqE, NONREC cVyy: jmp *-8(%r13), NONREC cUIr: jmp *(%rbx), NONREC cVyz: movq $block{v cUIq}_info,-40(%rbp) movq %rbx,%vI_sRPq movq 7(%rbx),%vI_sRPm movq 15(%rbx),%vI_sRPn movq 23(%rbx),%vI_sRPo movq %r14,%rbx movq %vI_sRPm,-32(%rbp) movq %vI_sRPn,-24(%rbp) movq %vI_sRPo,-16(%rbp) movq %vI_sRPq,-8(%rbp) addq $-40,%rbp testq $7,%rbx jne _cUIq jmp _cUIr, NONREC cVeU: leaq -64(%rbp),%vI_nWrJ cmpq %r15,%vI_nWrJ jb _cVyy jmp _cVyz, NONREC cVeY: movq 56(%rbp),%vI_cUJc movq 32(%rbp),%vI_sRPm movq 48(%rbp),%vI_sRPo movq 40(%rbp),%vI_sRYv movq 24(%rbp),%vI_sRYx movq 8(%rbp),%vI_sRYC movq 16(%rbp),%vI_sRYD addq $24,%rbp jmp _cVeX, NONREC cVxA: movq %vI_sRYD,%r14 movq %vI_cUJc,%rbx addq $40,%rbp jmp go9{v sRYB}_info, NONREC cVyo: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVyn: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUJc,-56(%r12) movq %vI_sRYD,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWte movq %vI_nWte,-32(%r12) movq 8(%rbp),%vI_nWtf movq %vI_nWtf,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWtg movq %vI_nWtg,-8(%r12) leaq -72(%r12),%vI_nWth movq %vI_nWth,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVyi: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVyo jmp _cVyn, NONREC cVfG: movq 32(%rbp),%vI_cUJc movq 16(%rbp),%vI_sRYD movq %rbx,%vI_nWrP andq $7,%vI_nWrP cmpq $2,%vI_nWrP jae _cVxA jmp _cVyi, NONREC cVxH: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVxG: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUJc,-56(%r12) movq %vI_sRYD,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWt9 movq %vI_nWt9,-32(%r12) movq 8(%rbp),%vI_nWta movq %vI_nWta,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWtb movq %vI_nWtb,-8(%r12) leaq -72(%r12),%vI_nWtc movq %vI_nWtc,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVxB: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVxH jmp _cVxG, NONREC cVgm: movq 32(%rbp),%vI_cUJc movq 16(%rbp),%vI_sRYD movq %rbx,%vI_nWrR andq $7,%vI_nWrR cmpq $2,%vI_nWrR jae _cVxA jmp _cVxB, NONREC cVgw: movq 56(%rbp),%vI_cUMN movq 32(%rbp),%vI_sRPm movq 48(%rbp),%vI_sRPo movq 40(%rbp),%vI_sRYv movq 24(%rbp),%vI_sRYx movq 8(%rbp),%vI_sRZS movq 16(%rbp),%vI_sRZT addq $24,%rbp jmp _cVgv, NONREC cVw3: movq %vI_sRZT,%r14 movq %vI_cUMN,%rbx addq $40,%rbp jmp go9{v sRZR}_info, NONREC cVwR: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVwQ: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUMN,-56(%r12) movq %vI_sRZT,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWt3 movq %vI_nWt3,-32(%r12) movq 8(%rbp),%vI_nWt4 movq %vI_nWt4,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWt5 movq %vI_nWt5,-8(%r12) leaq -72(%r12),%vI_nWt6 movq %vI_nWt6,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVwL: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVwR jmp _cVwQ, NONREC cVhe: movq 32(%rbp),%vI_cUMN movq 16(%rbp),%vI_sRZT movq %rbx,%vI_nWrT andq $7,%vI_nWrT cmpq $2,%vI_nWrT jae _cVw3 jmp _cVwL, NONREC cVwa: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVw9: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUMN,-56(%r12) movq %vI_sRZT,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWsY movq %vI_nWsY,-32(%r12) movq 8(%rbp),%vI_nWsZ movq %vI_nWsZ,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWt0 movq %vI_nWt0,-8(%r12) leaq -72(%r12),%vI_nWt1 movq %vI_nWt1,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVw4: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVwa jmp _cVw9, NONREC cVhU: movq 32(%rbp),%vI_cUMN movq 16(%rbp),%vI_sRZT movq %rbx,%vI_nWrV andq $7,%vI_nWrV cmpq $2,%vI_nWrV jae _cVw3 jmp _cVw4, NONREC cVi4: movq 56(%rbp),%vI_cUQr movq 32(%rbp),%vI_sRPm movq 48(%rbp),%vI_sRPo movq 40(%rbp),%vI_sRYv movq 24(%rbp),%vI_sRYx movq 8(%rbp),%vI_sS19 movq 16(%rbp),%vI_sS1a addq $24,%rbp jmp _cVi3, NONREC cVuw: movq %vI_sS1a,%r14 movq %vI_cUQr,%rbx addq $40,%rbp jmp go9{v sS18}_info, NONREC cVvk: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVvj: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUQr,-56(%r12) movq %vI_sS1a,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWsS movq %vI_nWsS,-32(%r12) movq 8(%rbp),%vI_nWsT movq %vI_nWsT,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsU movq %vI_nWsU,-8(%r12) leaq -72(%r12),%vI_nWsV movq %vI_nWsV,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVve: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVvk jmp _cVvj, NONREC cViM: movq 32(%rbp),%vI_cUQr movq 16(%rbp),%vI_sS1a movq %rbx,%vI_nWrX andq $7,%vI_nWrX cmpq $2,%vI_nWrX jae _cVuw jmp _cVve, NONREC cVuD: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVuC: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUQr,-56(%r12) movq %vI_sS1a,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWsN movq %vI_nWsN,-32(%r12) movq 8(%rbp),%vI_nWsO movq %vI_nWsO,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsP movq %vI_nWsP,-8(%r12) leaq -72(%r12),%vI_nWsQ movq %vI_nWsQ,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVux: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVuD jmp _cVuC, NONREC cVjs: movq 32(%rbp),%vI_cUQr movq 16(%rbp),%vI_sS1a movq %rbx,%vI_nWrZ andq $7,%vI_nWrZ cmpq $2,%vI_nWrZ jae _cVuw jmp _cVux, NONREC cVjC: movq 56(%rbp),%vI_cUU2 movq 32(%rbp),%vI_sRPm movq 48(%rbp),%vI_sRPo movq 40(%rbp),%vI_sRYv movq 24(%rbp),%vI_sRYx movq 8(%rbp),%vI_sS2p movq 16(%rbp),%vI_sS2q addq $24,%rbp jmp _cVjB, NONREC cVsZ: movq %vI_sS2q,%r14 movq %vI_cUU2,%rbx addq $40,%rbp jmp go9{v sS2o}_info, NONREC cVtN: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVtM: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUU2,-56(%r12) movq %vI_sS2q,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWsH movq %vI_nWsH,-32(%r12) movq 8(%rbp),%vI_nWsI movq %vI_nWsI,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsJ movq %vI_nWsJ,-8(%r12) leaq -72(%r12),%vI_nWsK movq %vI_nWsK,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVtH: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVtN jmp _cVtM, NONREC cVkk: movq 32(%rbp),%vI_cUU2 movq 16(%rbp),%vI_sS2q movq %rbx,%vI_nWs1 andq $7,%vI_nWs1 cmpq $2,%vI_nWs1 jae _cVsZ jmp _cVtH, NONREC cVt6: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVt5: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUU2,-56(%r12) movq %vI_sS2q,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWsC movq %vI_nWsC,-32(%r12) movq 8(%rbp),%vI_nWsD movq %vI_nWsD,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsE movq %vI_nWsE,-8(%r12) leaq -72(%r12),%vI_nWsF movq %vI_nWsF,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVt0: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVt6 jmp _cVt5, NONREC cVl0: movq 32(%rbp),%vI_cUU2 movq 16(%rbp),%vI_sS2q movq %rbx,%vI_nWs3 andq $7,%vI_nWs3 cmpq $2,%vI_nWs3 jae _cVsZ jmp _cVt0, NONREC cVlc: movq 56(%rbp),%vI_cV7D movq 32(%rbp),%vI_sRPm movq 48(%rbp),%vI_sRPo movq 40(%rbp),%vI_sRYv movq 24(%rbp),%vI_sRYx movq 16(%rbp),%vI_sS4V movq 8(%rbp),%vI_sS4W addq $8,%rbp jmp _cVlb, NONREC cVro: movq %vI_sS4W,%r14 movq %vI_cV7D,%rbx addq $48,%rbp jmp go9{v sS4U}_info, NONREC cVsc: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVsb: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cV7D,-56(%r12) movq %vI_sS4W,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 8(%rbp),%vI_nWst movq %vI_nWst,-32(%r12) movq 24(%rbp),%vI_nWsu movq %vI_nWsu,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsv movq %vI_nWsv,-8(%r12) leaq -72(%r12),%vI_nWsw movq %vI_nWsw,(%r12) leaq -14(%r12),%rbx addq $48,%rbp jmp *(%rbp), NONREC cVs6: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVsc jmp _cVsb, NONREC cVlU: movq 40(%rbp),%vI_cV7D movq 32(%rbp),%vI_sS4W movq %rbx,%vI_nWs5 andq $7,%vI_nWs5 cmpq $2,%vI_nWs5 jae _cVro jmp _cVs6, NONREC cVrv: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVru: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cV7D,-56(%r12) movq %vI_sS4W,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 8(%rbp),%vI_nWso movq %vI_nWso,-32(%r12) movq 24(%rbp),%vI_nWsp movq %vI_nWsp,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsq movq %vI_nWsq,-8(%r12) leaq -72(%r12),%vI_nWsr movq %vI_nWsr,(%r12) leaq -14(%r12),%rbx addq $48,%rbp jmp *(%rbp), NONREC cVrp: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVrv jmp _cVru, NONREC cVmA: movq 40(%rbp),%vI_cV7D movq 32(%rbp),%vI_sS4W movq %rbx,%vI_nWs7 andq $7,%vI_nWs7 cmpq $2,%vI_nWs7 jae _cVro jmp _cVrp, NONREC cVq5: movq $24,904(%r13) jmp stg_gc_unpt_r1, NONREC cVpQ: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sS6f,-8(%r12) movq %vI_sS6k,(%r12) movq $block{v cVnu}_info,(%rbp) movq 16(%rbp),%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS6k,24(%rbp) movq %vI_sS6f,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVp7: addq $-24,%r12 movq %vI_sS6a,%r14 movq %vI_cVb9,%rbx addq $48,%rbp jmp go9{v sS68}_info, NONREC uVyK: movq %vI_sS6a,24(%rbp) jmp _cVp7, NONREC cVpK: cmpq $8,%vI_sS6k jl _cVpQ jmp _uVyK, NONREC uVyJ: movq %vI_sS6a,24(%rbp) jmp _cVp7, NONREC cVpE: movq 32(%rbp),%vI_sS6k addq 24(%rbp),%vI_sS6k testq %vI_sS6k,%vI_sS6k jge _cVpK jmp _uVyJ, NONREC uVyI: movq %vI_sS6a,24(%rbp) jmp _cVp7, NONREC cVpw: cmpq $8,%vI_sS6f jl _cVpE jmp _uVyI, NONREC uVyH: movq %vI_sS6a,24(%rbp) jmp _cVp7, NONREC cVpz: movq 40(%rbp),%vI_cVb9 movq 8(%rbp),%vI_sS6a movq 7(%rbx),%vI_sS6f testq %vI_sS6f,%vI_sS6f jge _cVpw jmp _uVyH, REC cVmX: addq $24,%r12 cmpq 856(%r13),%r12 ja _cVq5 jmp _cVpz cVpq: movq $block{v cVmX}_info,-8(%rbp) movq %vI_cUIx,%rbx movq %vI_sS6a,(%rbp) movq $-1,16(%rbp) movq %vI_cVb9,32(%rbp) addq $-8,%rbp testq $7,%rbx jne _cVmX jmp _cVmY, NONREC uVyL: addq $8,%rbp jmp _cVpd, NONREC cVq4: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVq3: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cVb9,-56(%r12) movq %vI_sS6a,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 32(%rbp),%vI_nWsi movq %vI_nWsi,-32(%r12) movq 24(%rbp),%vI_nWsj movq %vI_nWsj,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsk movq %vI_nWsk,-8(%r12) leaq -72(%r12),%vI_nWsl movq %vI_nWsl,(%r12) leaq -14(%r12),%rbx addq $48,%rbp jmp *(%rbp), NONREC cVpY: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVq4 jmp _cVq3, NONREC cVnu: movq 40(%rbp),%vI_cVb9 movq 8(%rbp),%vI_sS6a movq %rbx,%vI_nWs9 andq $7,%vI_nWs9 cmpq $2,%vI_nWs9 jae _uVyL jmp _cVpY, NONREC cVpl: movq $24,904(%r13) jmp stg_gc_unpt_r1, NONREC cVp6: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sS6v,-8(%r12) movq %vI_sS6A,(%r12) movq $block{v cVod}_info,8(%rbp) movq 16(%rbp),%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS6A,16(%rbp) movq %vI_sS6v,32(%rbp) addq $8,%rbp jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVp0: cmpq $8,%vI_sS6A jge _cVp7 jmp _cVp6, NONREC cVoU: movq 32(%rbp),%vI_sS6A addq 8(%rbp),%vI_sS6A testq %vI_sS6A,%vI_sS6A jl _cVp7 jmp _cVp0, NONREC cVoM: cmpq $8,%vI_sS6v jge _cVp7 jmp _cVoU, NONREC cVoP: movq 40(%rbp),%vI_cVb9 movq 24(%rbp),%vI_sS6a movq 7(%rbx),%vI_sS6v testq %vI_sS6v,%vI_sS6v jl _cVp7 jmp _cVoM, REC cVnG: addq $24,%r12 cmpq 856(%r13),%r12 ja _cVpl jmp _cVoP cVoG: movq $block{v cVnG}_info,-8(%rbp) movq %vI_cUIx,%rbx movq $-1,(%rbp) movq %vI_sS6a,16(%rbp) movq %vI_cVb9,32(%rbp) addq $-8,%rbp testq $7,%rbx jne _cVnG jmp _cVnH cVoD: movl $a4{v rRvU}_closure+2,%vI_sS6a jmp _cVoG, NONREC cVpk: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVpj: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cVb9,-56(%r12) movq %vI_sS6a,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWsd movq %vI_nWsd,-32(%r12) movq 8(%rbp),%vI_nWse movq %vI_nWse,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsf movq %vI_nWsf,-8(%r12) leaq -72(%r12),%vI_nWsg movq %vI_nWsg,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVpe: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVpk jmp _cVpj, NONREC cVod: movq 32(%rbp),%vI_cVb9 movq 16(%rbp),%vI_sS6a movq %rbx,%vI_nWsb andq $7,%vI_nWsb cmpq $2,%vI_nWsb jae _cVpd jmp _cVpe] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Error when running Shake build system: * exercise_list * BooleansExercise Development.Shake.cmd, system command failed Command: ghc --make -O2 BooleansExercise Exit code: 1 Stderr: ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): RegAlloc.Liveness.computeLivenss SCCs aren't in reverse dependent order bad blockId cVmY [NONREC cVyv: movq $64,904(%r13) jmp stg_gc_unpt_r1, NONREC cVyr: movq $40,904(%r13) movq $block{v cUIX}_info,(%rbp) movq %vI_sRYu,%rbx jmp stg_gc_unbx_r1, NONREC cVyq: movq $48,904(%r13) jmp stg_gc_unpt_r1, NONREC cVqw: movq $main:Main.S{d riit}_con_info,-40(%r12) movq %vI_sRYx,-32(%r12) movq %vI_sS14,-24(%r12) leaq -39(%r12),%vI_cV0M addq $-24,%r12 movq $block{v cV0N}_info,-16(%rbp) movq %vI_sRPm,%rdi movq %vI_cV0M,%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS14,-8(%rbp) movq %vI_sRYx,(%rbp) addq $-16,%rbp jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVtO: movq $24,904(%r13) movq $block{v cVjC}_info,-24(%rbp) movq %vI_sS2p,-16(%rbp) movq %vI_sS2q,-8(%rbp) movq %vI_sRYx,(%rbp) movq %vI_cUU2,32(%rbp) addq $-24,%rbp jmp stg_gc_noregs, NONREC cVsT: addq $-24,%r12 movq %vI_sS2q,%r14 movq %vI_cUU2,%rbx addq $40,%rbp jmp go9{v sS2o}_info, NONREC cVsS: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS2P,(%r12) movq $block{v cVl0}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS2P,8(%rbp) movq %vI_sS2q,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUU2,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVsM: cmpq $8,%vI_sS2P jge _cVsT jmp _cVsS, NONREC cVsG: movq %vI_sRPo,%vI_sS2P addq %vI_sS2p,%vI_sS2P testq %vI_sS2P,%vI_sS2P jl _cVsT jmp _cVsM, NONREC cVsA: cmpq $8,%vI_sRYx jge _cVsT jmp _cVsG, NONREC cVsu: testq %vI_sRYx,%vI_sRYx jl _cVsT jmp _cVsA, NONREC cVsm: cmpq %vI_sS2p,%vI_sRYv je _cVsT jmp _cVsu, NONREC cVtz: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS2A,(%r12) movq $block{v cVkk}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS2A,8(%rbp) movq %vI_sS2q,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUU2,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVtt: cmpq $8,%vI_sS2A jge _cVsT jmp _cVtz, NONREC cVtn: movq %vI_sRPo,%vI_sS2A addq %vI_sS2p,%vI_sS2A testq %vI_sS2A,%vI_sS2A jl _cVsT jmp _cVtt, NONREC cVth: cmpq $8,%vI_sRYx jge _cVsT jmp _cVtn, NONREC cVtb: testq %vI_sRYx,%vI_sRYx jl _cVsT jmp _cVth, NONREC cVsn: movq %vI_sS2p,%vI_nWsA negq %vI_nWsA cmpq %vI_nWsA,%vI_sRYv je _cVsT jmp _cVtb, NONREC cVsp: testq %vI_sS2p,%vI_sS2p jge _cVsm jmp _cVsn, NONREC cVjB: addq $24,%r12 cmpq 856(%r13),%r12 ja _cVtO jmp _cVsp, NONREC cVqx: movq $go9{v sS2o}_info,-40(%r12) movq %vI_sRPm,-32(%r12) movq %vI_cUIw,-24(%r12) movq %vI_sRPo,-16(%r12) movq %vI_sRYv,-8(%r12) movq %vI_sRYx,(%r12) leaq -39(%r12),%vI_cUU2 movl $a4{v rRvU}_closure+2,%vI_sS2q movq $-1,%vI_sS2p jmp _cVjB, NONREC cVqq: cmpq $8,%vI_sS14 jl _cVqw jmp _cVqx, NONREC cVvl: movq $24,904(%r13) movq $block{v cVi4}_info,-24(%rbp) movq %vI_sS19,-16(%rbp) movq %vI_sS1a,-8(%rbp) movq %vI_sRYx,(%rbp) movq %vI_cUQr,32(%rbp) addq $-24,%rbp jmp stg_gc_noregs, NONREC cVuq: addq $-24,%r12 movq %vI_sS1a,%r14 movq %vI_cUQr,%rbx addq $40,%rbp jmp go9{v sS18}_info, NONREC cVup: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS1z,(%r12) movq $block{v cVjs}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS1z,8(%rbp) movq %vI_sS1a,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUQr,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVuj: cmpq $8,%vI_sS1z jge _cVuq jmp _cVup, NONREC cVud: movq %vI_sRPo,%vI_sS1z addq %vI_sS19,%vI_sS1z testq %vI_sS1z,%vI_sS1z jl _cVuq jmp _cVuj, NONREC cVu7: cmpq $8,%vI_sRYx jge _cVuq jmp _cVud, NONREC cVu1: testq %vI_sRYx,%vI_sRYx jl _cVuq jmp _cVu7, NONREC cVtT: cmpq %vI_sS19,%vI_sRYv je _cVuq jmp _cVu1, NONREC cVv6: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS1k,(%r12) movq $block{v cViM}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS1k,8(%rbp) movq %vI_sS1a,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUQr,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVv0: cmpq $8,%vI_sS1k jge _cVuq jmp _cVv6, NONREC cVuU: movq %vI_sRPo,%vI_sS1k addq %vI_sS19,%vI_sS1k testq %vI_sS1k,%vI_sS1k jl _cVuq jmp _cVv0, NONREC cVuO: cmpq $8,%vI_sRYx jge _cVuq jmp _cVuU, NONREC cVuI: testq %vI_sRYx,%vI_sRYx jl _cVuq jmp _cVuO, NONREC cVtU: movq %vI_sS19,%vI_nWsL negq %vI_nWsL cmpq %vI_nWsL,%vI_sRYv je _cVuq jmp _cVuI, NONREC cVtW: testq %vI_sS19,%vI_sS19 jge _cVtT jmp _cVtU, NONREC cVi3: addq $24,%r12 cmpq 856(%r13),%r12 ja _cVvl jmp _cVtW, NONREC cVqr: movq $go9{v sS18}_info,-40(%r12) movq %vI_sRPm,-32(%r12) movq %vI_cUIw,-24(%r12) movq %vI_sRPo,-16(%r12) movq %vI_sRYv,-8(%r12) movq %vI_sRYx,(%r12) leaq -39(%r12),%vI_cUQr movl $a4{v rRvU}_closure+2,%vI_sS1a movq $-1,%vI_sS19 jmp _cVi3, NONREC cVqk: leaq 1(%vI_sRPo),%vI_sS14 testq %vI_sS14,%vI_sS14 jge _cVqq jmp _cVqr, NONREC cVwS: movq $24,904(%r13) movq $block{v cVgw}_info,-24(%rbp) movq %vI_sRZS,-16(%rbp) movq %vI_sRZT,-8(%rbp) movq %vI_sRYx,(%rbp) movq %vI_cUMN,32(%rbp) addq $-24,%rbp jmp stg_gc_noregs, NONREC cVvX: addq $-24,%r12 movq %vI_sRZT,%r14 movq %vI_cUMN,%rbx addq $40,%rbp jmp go9{v sRZR}_info, NONREC cVvW: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS0i,(%r12) movq $block{v cVhU}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS0i,8(%rbp) movq %vI_sRZT,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUMN,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVvQ: cmpq $8,%vI_sS0i jge _cVvX jmp _cVvW, NONREC cVvK: movq %vI_sRPo,%vI_sS0i addq %vI_sRZS,%vI_sS0i testq %vI_sS0i,%vI_sS0i jl _cVvX jmp _cVvQ, NONREC cVvE: cmpq $8,%vI_sRYx jge _cVvX jmp _cVvK, NONREC cVvy: testq %vI_sRYx,%vI_sRYx jl _cVvX jmp _cVvE, NONREC cVvq: cmpq %vI_sRZS,%vI_sRYv je _cVvX jmp _cVvy, NONREC cVwD: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS03,(%r12) movq $block{v cVhe}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS03,8(%rbp) movq %vI_sRZT,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUMN,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVwx: cmpq $8,%vI_sS03 jge _cVvX jmp _cVwD, NONREC cVwr: movq %vI_sRPo,%vI_sS03 addq %vI_sRZS,%vI_sS03 testq %vI_sS03,%vI_sS03 jl _cVvX jmp _cVwx, NONREC cVwl: cmpq $8,%vI_sRYx jge _cVvX jmp _cVwr, NONREC cVwf: testq %vI_sRYx,%vI_sRYx jl _cVvX jmp _cVwl, NONREC cVvr: movq %vI_sRZS,%vI_nWsW negq %vI_nWsW cmpq %vI_nWsW,%vI_sRYv je _cVvX jmp _cVwf, NONREC cVvt: testq %vI_sRZS,%vI_sRZS jge _cVvq jmp _cVvr, NONREC cVgv: addq $24,%r12 cmpq 856(%r13),%r12 ja _cVwS jmp _cVvt, NONREC cVql: movq $go9{v sRZR}_info,-40(%r12) movq %vI_sRPm,-32(%r12) movq %vI_cUIw,-24(%r12) movq %vI_sRPo,-16(%r12) movq %vI_sRYv,-8(%r12) movq %vI_sRYx,(%r12) leaq -39(%r12),%vI_cUMN movl $a4{v rRvU}_closure+2,%vI_sRZT movq $-1,%vI_sRZS jmp _cVgv, NONREC cVqc: cmpq $8,%vI_sRYx jl _cVqk jmp _cVql, NONREC cVyp: movq $24,904(%r13) movq $block{v cVeY}_info,-24(%rbp) movq %vI_sRYC,-16(%rbp) movq %vI_sRYD,-8(%rbp) movq %vI_sRYx,(%rbp) movq %vI_cUJc,32(%rbp) addq $-24,%rbp jmp stg_gc_noregs, NONREC cVxu: addq $-24,%r12 movq %vI_sRYD,%r14 movq %vI_cUJc,%rbx addq $40,%rbp jmp go9{v sRYB}_info, NONREC cVxt: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sRZ2,(%r12) movq $block{v cVgm}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sRZ2,8(%rbp) movq %vI_sRYD,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUJc,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVxn: cmpq $8,%vI_sRZ2 jge _cVxu jmp _cVxt, NONREC cVxh: movq %vI_sRPo,%vI_sRZ2 addq %vI_sRYC,%vI_sRZ2 testq %vI_sRZ2,%vI_sRZ2 jl _cVxu jmp _cVxn, NONREC cVxb: cmpq $8,%vI_sRYx jge _cVxu jmp _cVxh, NONREC cVx5: testq %vI_sRYx,%vI_sRYx jl _cVxu jmp _cVxb, NONREC cVwX: cmpq %vI_sRYC,%vI_sRYv je _cVxu jmp _cVx5, NONREC cVya: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sRYN,(%r12) movq $block{v cVfG}_info,(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sRYN,8(%rbp) movq %vI_sRYD,16(%rbp) movq %vI_sRYx,24(%rbp) movq %vI_cUJc,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVy4: cmpq $8,%vI_sRYN jge _cVxu jmp _cVya, NONREC cVxY: movq %vI_sRPo,%vI_sRYN addq %vI_sRYC,%vI_sRYN testq %vI_sRYN,%vI_sRYN jl _cVxu jmp _cVy4, NONREC cVxS: cmpq $8,%vI_sRYx jge _cVxu jmp _cVxY, NONREC cVxM: testq %vI_sRYx,%vI_sRYx jl _cVxu jmp _cVxS, NONREC cVwY: movq %vI_sRYC,%vI_nWt7 negq %vI_nWt7 cmpq %vI_nWt7,%vI_sRYv je _cVxu jmp _cVxM, NONREC cVx0: testq %vI_sRYC,%vI_sRYC jge _cVwX jmp _cVwY, NONREC cVeX: addq $24,%r12 cmpq 856(%r13),%r12 ja _cVyp jmp _cVx0, NONREC cVqd: movq $go9{v sRYB}_info,-40(%r12) movq %vI_sRPm,-32(%r12) movq %vI_cUIw,-24(%r12) movq %vI_sRPo,-16(%r12) movq %vI_sRYv,-8(%r12) movq %vI_sRYx,(%r12) leaq -39(%r12),%vI_cUJc movl $a4{v rRvU}_closure+2,%vI_sRYD movq $-1,%vI_sRYC jmp _cVeX, NONREC cVqf: movq 32(%rbp),%vI_cUIw movq 8(%rbp),%vI_sRPm movq 24(%rbp),%vI_sRPo movq 16(%rbp),%vI_sRYv movq 7(%rbx),%vI_sRYx testq %vI_sRYx,%vI_sRYx jge _cVqc jmp _cVqd, NONREC cUJ2: addq $48,%r12 cmpq 856(%r13),%r12 ja _cVyq jmp _cVqf, NONREC cUJ3: jmp *(%rbx), NONREC cVox: addq $-40,%r12 movq $block{v cUJ2}_info,(%rbp) movq %vI_cUIx,%rbx movq %vI_sRYu,16(%rbp) testq $7,%rbx jne _cUJ2 jmp _cUJ3, NONREC cVpd: movq %vI_sS6a,%r14 movq %vI_cVb9,%rbx addq $40,%rbp jmp go9{v sS68}_info, NONREC cVoE: movl $a4{v rRvU}_closure+2,%vI_sS6a jmp _cVpd, NONREC cVoy: movq $go9{v sS68}_info,-32(%r12) movq %vI_sRPm,-24(%r12) movq %vI_cUIw,-16(%r12) movq %vI_cUIx,-8(%r12) movq %vI_sRPo,(%r12) leaq -31(%r12),%vI_cVb9 jmp _cVoE, NONREC cVow: cmpq $1,%vI_sRYu jne _cVox jmp _cVoy, NONREC cUIY: addq $40,%r12 cmpq 856(%r13),%r12 ja _cVyr jmp _cVow, NONREC cVos: movq %vI_sRYs,%vI_sRYu jmp _cUIY, NONREC cVot: movq %vI_sRYs,%vI_sRYu negq %vI_sRYu jmp _cUIY, NONREC cUIQ: movq 32(%rbp),%vI_cUIw movq 16(%rbp),%vI_cUIx movq 8(%rbp),%vI_sRPm movq 24(%rbp),%vI_sRPo movq 7(%rbx),%vI_sRYs testq %vI_sRYs,%vI_sRYs jge _cVos jmp _cVot, NONREC cUIR: jmp *(%rbx), NONREC cVyu: movq 6(%rbx),%vI_sRYk movq 14(%rbx),%vI_sRYl movq $stg_ap_2_upd_info,-56(%r12) movq 32(%rbp),%vI_nWti movq %vI_nWti,-40(%r12) movq %vI_sRYl,-32(%r12) movq $lvl60{v sRYn}_info,-24(%r12) movq %vI_sRYk,-8(%r12) movq 16(%rbp),%vI_nWtj movq %vI_nWtj,(%r12) movq $block{v cUIQ}_info,(%rbp) movq %vI_sRYk,%rbx leaq -24(%r12),%vI_nWtk movq %vI_nWtk,16(%rbp) leaq -56(%r12),%vI_nWtl movq %vI_nWtl,32(%rbp) testq $7,%rbx jne _cUIQ jmp _cUIR, NONREC cVeS: addq $64,%r12 cmpq 856(%r13),%r12 ja _cVyv jmp _cVyu, NONREC cVeT: movl $ghc-prim:GHC.Types.[]{(w) d 6m}_closure+1,%ebx addq $40,%rbp jmp *(%rbp), NONREC cUIq: movq %rbx,%vI_nWrL andq $7,%vI_nWrL cmpq $2,%vI_nWrL jae _cVeS jmp _cVeT, NONREC cUIX: movq 32(%rbp),%vI_cUIw movq 16(%rbp),%vI_cUIx movq 8(%rbp),%vI_sRPm movq 24(%rbp),%vI_sRPo movq %rbx,%vI_sRYu jmp _cUIY, NONREC cVse: movq $48,904(%r13) jmp stg_gc_unpt_r1, NONREC cVsd: movq $24,904(%r13) movq $block{v cVlc}_info,-8(%rbp) movq %vI_sS4W,(%rbp) movq %vI_sS4V,8(%rbp) movq %vI_cV7D,48(%rbp) addq $-8,%rbp jmp stg_gc_noregs, NONREC cVri: addq $-24,%r12 movq %vI_sS4W,%r14 movq %vI_cV7D,%rbx addq $56,%rbp jmp go9{v sS4U}_info, NONREC cVrh: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS5l,(%r12) movq $block{v cVmA}_info,8(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS5l,32(%rbp) movq %vI_sS4W,40(%rbp) movq %vI_cV7D,48(%rbp) addq $8,%rbp jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVrb: cmpq $8,%vI_sS5l jge _cVri jmp _cVrh, NONREC cVr5: movq %vI_sRPo,%vI_sS5l addq %vI_sS4V,%vI_sS5l testq %vI_sS5l,%vI_sS5l jl _cVri jmp _cVrb, NONREC cVqZ: cmpq $8,%vI_sRYx jge _cVri jmp _cVr5, NONREC cVqT: testq %vI_sRYx,%vI_sRYx jl _cVri jmp _cVqZ, NONREC cVqL: cmpq %vI_sS4V,%vI_sRYv je _cVri jmp _cVqT, NONREC cVrY: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sRYx,-8(%r12) movq %vI_sS56,(%r12) movq $block{v cVlU}_info,8(%rbp) movq %vI_sRPm,%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS56,32(%rbp) movq %vI_sS4W,40(%rbp) movq %vI_cV7D,48(%rbp) addq $8,%rbp jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVrS: cmpq $8,%vI_sS56 jge _cVri jmp _cVrY, NONREC cVrM: movq %vI_sRPo,%vI_sS56 addq %vI_sS4V,%vI_sS56 testq %vI_sS56,%vI_sS56 jl _cVri jmp _cVrS, NONREC cVrG: cmpq $8,%vI_sRYx jge _cVri jmp _cVrM, NONREC cVrA: testq %vI_sRYx,%vI_sRYx jl _cVri jmp _cVrG, NONREC cVqM: movq %vI_sS4V,%vI_nWsm negq %vI_nWsm cmpq %vI_nWsm,%vI_sRYv je _cVri jmp _cVrA, NONREC cVqO: testq %vI_sS4V,%vI_sS4V jge _cVqL jmp _cVqM, NONREC cVlb: addq $24,%r12 cmpq 856(%r13),%r12 ja _cVsd jmp _cVqO, NONREC cVqG: movq $go9{v sS4U}_info,-40(%r12) movq %vI_sRPm,-32(%r12) movq %vI_cUIw,-24(%r12) movq %vI_sRPo,-16(%r12) movq %vI_sRYv,-8(%r12) movq %vI_sRYx,(%r12) leaq -39(%r12),%vI_cV7D movl $a4{v rRvU}_closure+2,%vI_sS4W movq $-1,%vI_sS4V jmp _cVlb, NONREC cVqD: addq $48,%r12 cmpq 856(%r13),%r12 ja _cVse jmp _cVqG, NONREC cVsh: movq $104,904(%r13) jmp stg_gc_unpt_r1, NONREC cVsg: movq $sat_sS4S{v}_info,-96(%r12) movq %vI_sRPm,-80(%r12) movq %vI_cUIw,-72(%r12) movq %vI_sRPo,-64(%r12) movq %vI_sRYv,-56(%r12) movq %vI_sRYx,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq %vI_sRYx,-32(%r12) movq 8(%rbp),%vI_nWsx movq %vI_nWsx,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsy movq %vI_nWsy,-8(%r12) leaq -96(%r12),%vI_nWsz movq %vI_nWsz,(%r12) leaq -14(%r12),%rbx addq $56,%rbp jmp *(%rbp), NONREC cVqE: addq $104,%r12 cmpq 856(%r13),%r12 ja _cVsh jmp _cVsg, NONREC cV0N: movq 48(%rbp),%vI_cUIw movq 24(%rbp),%vI_sRPm movq 40(%rbp),%vI_sRPo movq 32(%rbp),%vI_sRYv movq 16(%rbp),%vI_sRYx movq %rbx,%vI_nWrN andq $7,%vI_nWrN cmpq $2,%vI_nWrN jae _cVqD jmp _cVqE, NONREC cVyy: jmp *-8(%r13), NONREC cUIr: jmp *(%rbx), NONREC cVyz: movq $block{v cUIq}_info,-40(%rbp) movq %rbx,%vI_sRPq movq 7(%rbx),%vI_sRPm movq 15(%rbx),%vI_sRPn movq 23(%rbx),%vI_sRPo movq %r14,%rbx movq %vI_sRPm,-32(%rbp) movq %vI_sRPn,-24(%rbp) movq %vI_sRPo,-16(%rbp) movq %vI_sRPq,-8(%rbp) addq $-40,%rbp testq $7,%rbx jne _cUIq jmp _cUIr, NONREC cVeU: leaq -64(%rbp),%vI_nWrJ cmpq %r15,%vI_nWrJ jb _cVyy jmp _cVyz, NONREC cVeY: movq 56(%rbp),%vI_cUJc movq 32(%rbp),%vI_sRPm movq 48(%rbp),%vI_sRPo movq 40(%rbp),%vI_sRYv movq 24(%rbp),%vI_sRYx movq 8(%rbp),%vI_sRYC movq 16(%rbp),%vI_sRYD addq $24,%rbp jmp _cVeX, NONREC cVxA: movq %vI_sRYD,%r14 movq %vI_cUJc,%rbx addq $40,%rbp jmp go9{v sRYB}_info, NONREC cVyo: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVyn: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUJc,-56(%r12) movq %vI_sRYD,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWte movq %vI_nWte,-32(%r12) movq 8(%rbp),%vI_nWtf movq %vI_nWtf,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWtg movq %vI_nWtg,-8(%r12) leaq -72(%r12),%vI_nWth movq %vI_nWth,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVyi: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVyo jmp _cVyn, NONREC cVfG: movq 32(%rbp),%vI_cUJc movq 16(%rbp),%vI_sRYD movq %rbx,%vI_nWrP andq $7,%vI_nWrP cmpq $2,%vI_nWrP jae _cVxA jmp _cVyi, NONREC cVxH: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVxG: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUJc,-56(%r12) movq %vI_sRYD,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWt9 movq %vI_nWt9,-32(%r12) movq 8(%rbp),%vI_nWta movq %vI_nWta,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWtb movq %vI_nWtb,-8(%r12) leaq -72(%r12),%vI_nWtc movq %vI_nWtc,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVxB: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVxH jmp _cVxG, NONREC cVgm: movq 32(%rbp),%vI_cUJc movq 16(%rbp),%vI_sRYD movq %rbx,%vI_nWrR andq $7,%vI_nWrR cmpq $2,%vI_nWrR jae _cVxA jmp _cVxB, NONREC cVgw: movq 56(%rbp),%vI_cUMN movq 32(%rbp),%vI_sRPm movq 48(%rbp),%vI_sRPo movq 40(%rbp),%vI_sRYv movq 24(%rbp),%vI_sRYx movq 8(%rbp),%vI_sRZS movq 16(%rbp),%vI_sRZT addq $24,%rbp jmp _cVgv, NONREC cVw3: movq %vI_sRZT,%r14 movq %vI_cUMN,%rbx addq $40,%rbp jmp go9{v sRZR}_info, NONREC cVwR: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVwQ: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUMN,-56(%r12) movq %vI_sRZT,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWt3 movq %vI_nWt3,-32(%r12) movq 8(%rbp),%vI_nWt4 movq %vI_nWt4,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWt5 movq %vI_nWt5,-8(%r12) leaq -72(%r12),%vI_nWt6 movq %vI_nWt6,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVwL: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVwR jmp _cVwQ, NONREC cVhe: movq 32(%rbp),%vI_cUMN movq 16(%rbp),%vI_sRZT movq %rbx,%vI_nWrT andq $7,%vI_nWrT cmpq $2,%vI_nWrT jae _cVw3 jmp _cVwL, NONREC cVwa: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVw9: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUMN,-56(%r12) movq %vI_sRZT,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWsY movq %vI_nWsY,-32(%r12) movq 8(%rbp),%vI_nWsZ movq %vI_nWsZ,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWt0 movq %vI_nWt0,-8(%r12) leaq -72(%r12),%vI_nWt1 movq %vI_nWt1,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVw4: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVwa jmp _cVw9, NONREC cVhU: movq 32(%rbp),%vI_cUMN movq 16(%rbp),%vI_sRZT movq %rbx,%vI_nWrV andq $7,%vI_nWrV cmpq $2,%vI_nWrV jae _cVw3 jmp _cVw4, NONREC cVi4: movq 56(%rbp),%vI_cUQr movq 32(%rbp),%vI_sRPm movq 48(%rbp),%vI_sRPo movq 40(%rbp),%vI_sRYv movq 24(%rbp),%vI_sRYx movq 8(%rbp),%vI_sS19 movq 16(%rbp),%vI_sS1a addq $24,%rbp jmp _cVi3, NONREC cVuw: movq %vI_sS1a,%r14 movq %vI_cUQr,%rbx addq $40,%rbp jmp go9{v sS18}_info, NONREC cVvk: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVvj: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUQr,-56(%r12) movq %vI_sS1a,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWsS movq %vI_nWsS,-32(%r12) movq 8(%rbp),%vI_nWsT movq %vI_nWsT,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsU movq %vI_nWsU,-8(%r12) leaq -72(%r12),%vI_nWsV movq %vI_nWsV,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVve: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVvk jmp _cVvj, NONREC cViM: movq 32(%rbp),%vI_cUQr movq 16(%rbp),%vI_sS1a movq %rbx,%vI_nWrX andq $7,%vI_nWrX cmpq $2,%vI_nWrX jae _cVuw jmp _cVve, NONREC cVuD: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVuC: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUQr,-56(%r12) movq %vI_sS1a,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWsN movq %vI_nWsN,-32(%r12) movq 8(%rbp),%vI_nWsO movq %vI_nWsO,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsP movq %vI_nWsP,-8(%r12) leaq -72(%r12),%vI_nWsQ movq %vI_nWsQ,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVux: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVuD jmp _cVuC, NONREC cVjs: movq 32(%rbp),%vI_cUQr movq 16(%rbp),%vI_sS1a movq %rbx,%vI_nWrZ andq $7,%vI_nWrZ cmpq $2,%vI_nWrZ jae _cVuw jmp _cVux, NONREC cVjC: movq 56(%rbp),%vI_cUU2 movq 32(%rbp),%vI_sRPm movq 48(%rbp),%vI_sRPo movq 40(%rbp),%vI_sRYv movq 24(%rbp),%vI_sRYx movq 8(%rbp),%vI_sS2p movq 16(%rbp),%vI_sS2q addq $24,%rbp jmp _cVjB, NONREC cVsZ: movq %vI_sS2q,%r14 movq %vI_cUU2,%rbx addq $40,%rbp jmp go9{v sS2o}_info, NONREC cVtN: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVtM: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUU2,-56(%r12) movq %vI_sS2q,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWsH movq %vI_nWsH,-32(%r12) movq 8(%rbp),%vI_nWsI movq %vI_nWsI,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsJ movq %vI_nWsJ,-8(%r12) leaq -72(%r12),%vI_nWsK movq %vI_nWsK,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVtH: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVtN jmp _cVtM, NONREC cVkk: movq 32(%rbp),%vI_cUU2 movq 16(%rbp),%vI_sS2q movq %rbx,%vI_nWs1 andq $7,%vI_nWs1 cmpq $2,%vI_nWs1 jae _cVsZ jmp _cVtH, NONREC cVt6: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVt5: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cUU2,-56(%r12) movq %vI_sS2q,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWsC movq %vI_nWsC,-32(%r12) movq 8(%rbp),%vI_nWsD movq %vI_nWsD,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsE movq %vI_nWsE,-8(%r12) leaq -72(%r12),%vI_nWsF movq %vI_nWsF,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVt0: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVt6 jmp _cVt5, NONREC cVl0: movq 32(%rbp),%vI_cUU2 movq 16(%rbp),%vI_sS2q movq %rbx,%vI_nWs3 andq $7,%vI_nWs3 cmpq $2,%vI_nWs3 jae _cVsZ jmp _cVt0, NONREC cVlc: movq 56(%rbp),%vI_cV7D movq 32(%rbp),%vI_sRPm movq 48(%rbp),%vI_sRPo movq 40(%rbp),%vI_sRYv movq 24(%rbp),%vI_sRYx movq 16(%rbp),%vI_sS4V movq 8(%rbp),%vI_sS4W addq $8,%rbp jmp _cVlb, NONREC cVro: movq %vI_sS4W,%r14 movq %vI_cV7D,%rbx addq $48,%rbp jmp go9{v sS4U}_info, NONREC cVsc: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVsb: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cV7D,-56(%r12) movq %vI_sS4W,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 8(%rbp),%vI_nWst movq %vI_nWst,-32(%r12) movq 24(%rbp),%vI_nWsu movq %vI_nWsu,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsv movq %vI_nWsv,-8(%r12) leaq -72(%r12),%vI_nWsw movq %vI_nWsw,(%r12) leaq -14(%r12),%rbx addq $48,%rbp jmp *(%rbp), NONREC cVs6: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVsc jmp _cVsb, NONREC cVlU: movq 40(%rbp),%vI_cV7D movq 32(%rbp),%vI_sS4W movq %rbx,%vI_nWs5 andq $7,%vI_nWs5 cmpq $2,%vI_nWs5 jae _cVro jmp _cVs6, NONREC cVrv: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVru: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cV7D,-56(%r12) movq %vI_sS4W,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 8(%rbp),%vI_nWso movq %vI_nWso,-32(%r12) movq 24(%rbp),%vI_nWsp movq %vI_nWsp,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsq movq %vI_nWsq,-8(%r12) leaq -72(%r12),%vI_nWsr movq %vI_nWsr,(%r12) leaq -14(%r12),%rbx addq $48,%rbp jmp *(%rbp), NONREC cVrp: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVrv jmp _cVru, NONREC cVmA: movq 40(%rbp),%vI_cV7D movq 32(%rbp),%vI_sS4W movq %rbx,%vI_nWs7 andq $7,%vI_nWs7 cmpq $2,%vI_nWs7 jae _cVro jmp _cVrp, NONREC cVq5: movq $24,904(%r13) jmp stg_gc_unpt_r1, NONREC cVpQ: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sS6f,-8(%r12) movq %vI_sS6k,(%r12) movq $block{v cVnu}_info,(%rbp) movq 16(%rbp),%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS6k,24(%rbp) movq %vI_sS6f,32(%rbp) jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVp7: addq $-24,%r12 movq %vI_sS6a,%r14 movq %vI_cVb9,%rbx addq $48,%rbp jmp go9{v sS68}_info, NONREC uVyK: movq %vI_sS6a,24(%rbp) jmp _cVp7, NONREC cVpK: cmpq $8,%vI_sS6k jl _cVpQ jmp _uVyK, NONREC uVyJ: movq %vI_sS6a,24(%rbp) jmp _cVp7, NONREC cVpE: movq 32(%rbp),%vI_sS6k addq 24(%rbp),%vI_sS6k testq %vI_sS6k,%vI_sS6k jge _cVpK jmp _uVyJ, NONREC uVyI: movq %vI_sS6a,24(%rbp) jmp _cVp7, NONREC cVpw: cmpq $8,%vI_sS6f jl _cVpE jmp _uVyI, NONREC uVyH: movq %vI_sS6a,24(%rbp) jmp _cVp7, NONREC cVpz: movq 40(%rbp),%vI_cVb9 movq 8(%rbp),%vI_sS6a movq 7(%rbx),%vI_sS6f testq %vI_sS6f,%vI_sS6f jge _cVpw jmp _uVyH, REC cVmX: addq $24,%r12 cmpq 856(%r13),%r12 ja _cVq5 jmp _cVpz cVpq: movq $block{v cVmX}_info,-8(%rbp) movq %vI_cUIx,%rbx movq %vI_sS6a,(%rbp) movq $-1,16(%rbp) movq %vI_cVb9,32(%rbp) addq $-8,%rbp testq $7,%rbx jne _cVmX jmp _cVmY, NONREC uVyL: addq $8,%rbp jmp _cVpd, NONREC cVq4: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVq3: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cVb9,-56(%r12) movq %vI_sS6a,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 32(%rbp),%vI_nWsi movq %vI_nWsi,-32(%r12) movq 24(%rbp),%vI_nWsj movq %vI_nWsj,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsk movq %vI_nWsk,-8(%r12) leaq -72(%r12),%vI_nWsl movq %vI_nWsl,(%r12) leaq -14(%r12),%rbx addq $48,%rbp jmp *(%rbp), NONREC cVpY: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVq4 jmp _cVq3, NONREC cVnu: movq 40(%rbp),%vI_cVb9 movq 8(%rbp),%vI_sS6a movq %rbx,%vI_nWs9 andq $7,%vI_nWs9 cmpq $2,%vI_nWs9 jae _uVyL jmp _cVpY, NONREC cVpl: movq $24,904(%r13) jmp stg_gc_unpt_r1, NONREC cVp6: movq $main:Main.S{d riit}_con_info,-16(%r12) movq %vI_sS6v,-8(%r12) movq %vI_sS6A,(%r12) movq $block{v cVod}_info,8(%rbp) movq 16(%rbp),%rdi leaq -15(%r12),%rsi movl $main:Main.$fEqSquare{v riip}_closure+1,%r14d movq %vI_sS6A,16(%rbp) movq %vI_sS6v,32(%rbp) addq $8,%rbp jmp base:GHC.List.elem{v r1Ha}_info, NONREC cVp0: cmpq $8,%vI_sS6A jge _cVp7 jmp _cVp6, NONREC cVoU: movq 32(%rbp),%vI_sS6A addq 8(%rbp),%vI_sS6A testq %vI_sS6A,%vI_sS6A jl _cVp7 jmp _cVp0, NONREC cVoM: cmpq $8,%vI_sS6v jge _cVp7 jmp _cVoU, NONREC cVoP: movq 40(%rbp),%vI_cVb9 movq 24(%rbp),%vI_sS6a movq 7(%rbx),%vI_sS6v testq %vI_sS6v,%vI_sS6v jl _cVp7 jmp _cVoM, REC cVnG: addq $24,%r12 cmpq 856(%r13),%r12 ja _cVpl jmp _cVoP cVoG: movq $block{v cVnG}_info,-8(%rbp) movq %vI_cUIx,%rbx movq $-1,(%rbp) movq %vI_sS6a,16(%rbp) movq %vI_cVb9,32(%rbp) addq $-8,%rbp testq $7,%rbx jne _cVnG jmp _cVnH cVoD: movl $a4{v rRvU}_closure+2,%vI_sS6a jmp _cVoG, NONREC cVpk: movq $80,904(%r13) jmp stg_gc_unpt_r1, NONREC cVpj: movq $stg_ap_2_upd_info,-72(%r12) movq %vI_cVb9,-56(%r12) movq %vI_sS6a,-48(%r12) movq $main:Main.S{d riit}_con_info,-40(%r12) movq 24(%rbp),%vI_nWsd movq %vI_nWsd,-32(%r12) movq 8(%rbp),%vI_nWse movq %vI_nWse,-24(%r12) movq $ghc-prim:GHC.Types.:{(w) d 64}_con_info,-16(%r12) leaq -39(%r12),%vI_nWsf movq %vI_nWsf,-8(%r12) leaq -72(%r12),%vI_nWsg movq %vI_nWsg,(%r12) leaq -14(%r12),%rbx addq $40,%rbp jmp *(%rbp), NONREC cVpe: addq $80,%r12 cmpq 856(%r13),%r12 ja _cVpk jmp _cVpj, NONREC cVod: movq 32(%rbp),%vI_cVb9 movq 16(%rbp),%vI_sS6a movq %rbx,%vI_nWsb andq $7,%vI_nWsb cmpq $2,%vI_nWsb jae _cVpd jmp _cVpe] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler