July 2013 - ghc-tickets

[GHC] #8090: MetaKinds - PolyKinds generalization
by GHC 26 Jul '13

26 Jul '13

#8090: MetaKinds - PolyKinds generalization ------------------------------------+------------------------------------- Reporter: wvv | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- MetaKinds is more general then PolyKinds. Now we could write with PolyKinds {{{ class Foo (a :: k) where ... }}} It would be nice if we could also write with MetaKinds next: {{{ class Foo (a :: (k :: *)) where ... }}} As we already have Rank2Types and RankNTypes, PolyKinds ~ Rank2Types, MetaKinds ~ RankNTypes This will be valid: {{{ class Foo (a :: (k :: (u :: *))) where ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8090> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7814: panic in PPC NCG
by GHC 25 Jul '13

25 Jul '13

#7814: panic in PPC NCG ----------------------------------------+------------------------------ Reporter: heisenbug | Owner: heisenbug Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+------------------------------ Changes (by igloo): * status: new => infoneeded Comment: heisenbug, what's the status of this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7814#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7266: Allow fractional-looking integer literals
by GHC 24 Jul '13

24 Jul '13

#7266: Allow fractional-looking integer literals -------------------------------------+------------------------------------ Reporter: shachaf | Owner: Type: feature request | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 2245 -------------------------------------+------------------------------------ Changes (by igloo): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7266#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8083: setNumCapabilities broken in HEAD
by GHC 24 Jul '13

24 Jul '13

#8083: setNumCapabilities broken in HEAD --------------------------+------------------------------------------------ Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.7 Runtime System | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ {{{ #!haskell import GHC.Conc import Control.Monad main :: IO () main = do n <- getNumCapabilities when (n == 1) $ setNumCapabilities 2 print () }}} One would expect this program to print () just once, but when compiled with -O or -O2 it prints () repeatedly and indefinitely! This doesn't happen on GHC 7.6.2 or 7.4.1, only on HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8083> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #7970: Thread GC frees roots before thread actually finishes
by GHC 24 Jul '13

24 Jul '13

#7970: Thread GC frees roots before thread actually finishes -------------------------------------+------------------------------------ Reporter: joeyadams | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 7170 -------------------------------------+------------------------------------ Comment (by simonmar): Fixed this, thanks Edward. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7970#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8088: Disposable types language extension
by GHC 24 Jul '13

24 Jul '13

#8088: Disposable types language extension ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- The disposable types language extension would serve as a way of allowing the garbage collector to clean up things which require destroying handles, closing resources, etc to prevent resource exhaustion in code (even if exceptions occur) without adding transformer overhead like ResourceT. Consider the following example: {{{ {-# LANGUAGE DisposableTypes #-} class Dispose t where dispose :: t -> IO () instance Dispose SockHandle where dispose = disconnect }}} When the `SockHandle` is collected, the garbage collector runs its `dispose` method (and it's automatically disconnected and cleaned up). Similar principles could be applied to a file handle, shared memory etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8088> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8087: Bug in IO manager when increasing the number of capabilities
by GHC 23 Jul '13

23 Jul '13

#8087: Bug in IO manager when increasing the number of capabilities ------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The new IO manager in HEAD has a logic error in the function responsible for creating more IO manager threads after increasing the number of capabilities with `setNumCapabilities`. This results in an index-out-of- range error later on in the program when one perform blocking IO. Test case: {{{ #!haskell import GHC.Conc main = do setNumCapabilities 2 getLine }}} {{{ $ ghc-stage2 -threaded program.hs $ ./program program: Ix{Int}.index: Index (1) out of range ((0,0)) }}} The fix is simple and will be arriving shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5902: Cannot tell from an exception handler whether the exception was asynchronous
by GHC 23 Jul '13

23 Jul '13

#5902: Cannot tell from an exception handler whether the exception was asynchronous -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by igloo): I'm a bit confused now. If we only use `newUnsafePerformIO` (and not plain `unsafePerformIO`), then is it still possible for a `bracket` to be resumed? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5902#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7275: Give more detailed information about PINNED data in a heap profile
by GHC 23 Jul '13

23 Jul '13

#7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by igloo): * owner: igloo => Comment: Simon and I discussed this a while ago. Here's his summary of where we ended up: ---- I think what we want to do is basically mark-sweep on the BF_PINNED blocks when profiling (only). The main question is how to represent the mark bit: I think just using the low-order bit of the info pointer should be fine, since that's what we use for ordinary forwarding pointers too. Specifically: - in evacuate_large, if the block is BF_PINNED, mark the object by setting the low-order bit of its info table. (PROFILING only) - after the GC is finished, sweep all the BF_PINNED blocks that we touched, which can be found by traversing the scavenged_large_objects list of each generation. For each BF_PINNED block, walk through the memory zeroing out any unmarked ARR_WORDS objects, and unmarking the marked objects. - in allocatePinned, zero out any slop caused by alignment constraints. Then I believe the pinned memory can be traversed correctly by the heap profiler with no further changes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7275#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7779: building GHC overwrites the installed package database if GHC_PACKAGE_PATH is set
by GHC 23 Jul '13

23 Jul '13

#7779: building GHC overwrites the installed package database if GHC_PACKAGE_PATH is set -------------------------------------+------------------------------------ Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by igloo): * owner: igloo => Comment: Ah, I suspect you have an old version of `cabal`; it looks like 1.14 doesn't mind `GHC_PACKAGE_PATH` being set. But in 1.16 it just fails: {{{ $ cabal --version cabal-install version 1.16.0.2 using version 1.16.0 of the Cabal library $ export GHC_PACKAGE_PATH=something $ cabal install text cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times). $ echo $? 1 }}} You can use flags such as `-package-db` and `-global-package-db` with GHC too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7779#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0