December 2016 - ghc-tickets

[GHC] #12241: Surprising constructor accumulation
by GHC 30 Dec '16

30 Dec '16

#12241: Surprising constructor accumulation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `containers` version 0.5.7.1 (and a few earlier versions) uses the following implementation of `fromList` by Ross Paterson: {{{#!hs fromList :: [a] -> Seq a fromList = Seq . mkTree 1 . map_elem where {-# SPECIALIZE mkTree :: Int -> [Elem a] -> FingerTree (Elem a) #-} {-# SPECIALIZE mkTree :: Int -> [Node a] -> FingerTree (Node a) #-} mkTree :: (Sized a) => Int -> [a] -> FingerTree a mkTree !_ [] = EmptyT mkTree _ [x1] = Single x1 mkTree s [x1, x2] = Deep (2*s) (One x1) EmptyT (One x2) mkTree s [x1, x2, x3] = Deep (3*s) (One x1) EmptyT (Two x2 x3) mkTree s (x1:x2:x3:x4:xs) = case getNodes (3*s) x4 xs of (ns, sf) -> case mkTree (3*s) ns of !m -> Deep (3*size x1 + size m + size sf) (Three x1 x2 x3) m sf getNodes :: Int -> a -> [a] -> ([Node a], Digit a) getNodes !_ x1 [] = ([], One x1) getNodes _ x1 [x2] = ([], Two x1 x2) getNodes _ x1 [x2, x3] = ([], Three x1 x2 x3) getNodes s x1 (x2:x3:x4:xs) = (Node3 s x1 x2 x3:ns, d) where (ns, d) = getNodes s x4 xs map_elem :: [a] -> [Elem a] #if __GLASGOW_HASKELL__ >= 708 map_elem xs = coerce xs #else map_elem xs = Data.List.map Elem xs #endif {-# INLINE map_elem #-} }}} This uses one lazy list per "level" in the tree being constructed. I believe Paterson (and pretty much everyone else) expected that there would be `O(log n)` pair constructors and conses live at any given time. Wadler's technique in [http://homepages.inf.ed.ac.uk/wadler/papers/leak/leak.ps.gz Fixing some space leaks with a garbage collector], which the GHC commentary indicates is used in GHC, should clean up the pairs in `getNodes`'s `d` thunks as they reach WHNF. Lennart Spitzner dug into the unimpressive performance of the above code and using {{{#!hs main = evaluate $ S.fromList [(0::Int)..999999] }}} produced [http://heap.ezyang.com/view/72d4d1eb879a2085ffd49d270b03c7a037b4d5c2 this heap profile]. If I'm reading it right, this suggests that there are lots of `(,)` and also `(:)` constructors live, more `O(n)` than `O(log n)`. I had previously found that I could improve performance by building the intermediate lists strictly, but that violates the generational hypothesis and leads to a slow-down for very large arguments ([http://heap.ezyang.com/view/2e80598f73d9281f5eadfeb041f5b9aef6e448b0 Spitzner's heap profile]). Spitzner was able to come up with a very clever (but much trickier) implementation that skirted all these problems ([http://heap.ezyang.com/view/7f1994c0417931360fe7c41bd995c37ebc3fd6c5 profile]) and avoids ever allocating the troublesome pairs. So the problem is thoroughly bypassed for `containers`, but it seems like something is not quite right here, and it might bear looking into. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12241> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13036: educational purpose
by GHC 29 Dec '16

29 Dec '16

#13036: educational purpose -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For educational purpose : can we have in GHCi time set by a function to run as well as its occupation of memory by typing a command available from the prompt? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13036> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13034: clean memory in GHCi
by GHC 29 Dec '16

29 Dec '16

#13034: clean memory in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose you have a program that fills all memory up so what GHCi crash by displaying the "out of memory" error. But you don't know. You run the programm and a few seconds after you stop it by pressing ctrl-c. Then you start another programm that is correct like computing a factorial and suddenly GHCi crash. GHCi crash because there is not enough memory. All the values of the first program remained in memory and have not been deleted. Can we have a command available from the prompt that clean the memory? For example, Prelude> :clean memory or Prelude> :clm in order to avoid restart GHCi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12984: Missed constant folding oportunities (associativity)
by GHC 29 Dec '16

29 Dec '16

#12984: Missed constant folding oportunities (associativity) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this simple example: {{{#!hs import System.Environment main :: IO () main = do args <- getArgs print ((length args + 10) - 10) }}} Compiled with -O2, we get the following Core: {{{#!hs case GHC.Show.$wshowSignedInt 0# (GHC.Prim.-# (GHC.Prim.+# ww2_a6Pd 10#) 10#) (GHC.Types.[] @ Char) of }}} I would expect GHC to perform constant folding there to remove the unnecessary operation. Basically, for any expression composed of Int#/Word# +/-/* primops, I think we should use associativity and distributivity laws to push the constants in the outer operation. It would allow the "scrutinee constant folding" optimization to be applied more often too. I have a patch that does this for case scrutinees, but where should I put it in GHC so that the optimization gets applied more generally? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12984> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13039: Add options to select GHCi prompt type errors
by GHC 28 Dec '16

28 Dec '16

#13039: Add options to select GHCi prompt type errors -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: low | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [This SO post](http://stackoverflow.com/questions/41354231/how-can-i-set- up-haskells-ghci-to-interactively-evaluate-functions-to-their-sig) implicitly suggests some extra options for reporting type errors for expressions typed into GHCi. When GHCi reports a type error for an expression `e` typed at the prompt, it has effectively failed to check `void e :: IO ()` and `print e :: IO ()`. It always reports the error for the latter. There are three things a user may want, and I think options should control which ones are shown: 1. Why didn't `void e :: IO ()` check? 2. Why didn't `print e :: IO ()` check? 3. If any type could be inferred for `e`, what was it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13039> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary
by GHC 28 Dec '16

28 Dec '16

#13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- = Motivation = `read` is an easy way to introduce runtime exceptions into programs, but its documentation doesn't sufficiently warn of this danger. `read`'s safe alternatives, `Text.Read.readMaybe` and `Text.Read.readEither`, are relatively unknown and too hard to find. = Proposal = == Summary == 1. Add `readMaybe` to the `Prelude` 2. Add `readEither` to the `Prelude` 3. Change the documentation for `read` to point out the partiality and to recommend the above alternatives. == 3. Improve the documentation for `read` == The haddocks for `read` currently read: > The `read` function reads input from a string, which must be completely consumed by the input process. I propose to add the following paragraph: > Note: `read` will throw an error if the parse fails. > If there's any uncertainty w.r.t. the shape of the input, `readMaybe` or `readEither` should be used instead. == Qualifications == Ragarding point 2 (`readEither`), I have some qualms whether `readEither` ([http://hackage.haskell.org/package/base-4.9.0.0/docs/Text- Read.html#v:readEither docs]) offers sufficient additional benefit over `readMaybe` to also warrant inclusion in `Prelude`. While `readEither` does give additional info on the kind of parse failures, that information is encoded in a `String` error message, from which it must be parsed if it is needed in the program. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13013> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7930: Nested STM Invariants are lost
by GHC 28 Dec '16

28 Dec '16

#7930: Nested STM Invariants are lost -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: fryguybob Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: STM Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:1 fryguybob]: I believe the analysis is excellent. I only have some minor additional comments: > 2. The delay does not make sense because there are other effects that can > intervene before the transaction is committed! Indeed, it could be that > it will not hit the retry later on. Or an exception could happen due to > the very invariant property being checked (See example below). In fact, the effect does not even have to be external to the transaction, as demonstrated by the following single threaded example, which completes successfully instead of getting stuck retrying the transaction: {{{ import Control.Concurrent.STM main = do atomically $ do t <- newTVar True alwaysSucceeds $ do b <- readTVar t if b then retry else return () writeTVar t False putStrLn "Success" }}} Interestingly, there is no CHECK rule for the `retry` case in the operational semantics (Figure 4 of [1]), which could well explain this oversight. > This definition attempts to reuse the `retry` mechanism to handle the rollback of the initial run of the invariant. The rollback is (also?) necessary to ensure [D6]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7930#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #229: Integer overflow in array allocation
by GHC 27 Dec '16

27 Dec '16

#229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"f3b99c75fef7fc946a27de63edb5e6d6ad5a22be/ghc" f3b99c75/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f3b99c75fef7fc946a27de63edb5e6d6ad5a22be" Bump array submodule Fixes overflow check from fix to #229. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/229#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13037: educational purpose 2
by GHC 27 Dec '16

27 Dec '16

#13037: educational purpose 2 -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The goal is to have, in GHCi, the interim results provided by the function before the end result by a command available from the prompt, like this: for example:[[BR]] Prelude> g op n [] = n ; g op n (h:t) = h `op` g op n t[[BR]] Prelude> :stp[[BR]] Prelude> g (*) 2 [1..3][[BR]] 1* (*) 2 [2,3][[BR]] 1*2 (*) 2 [3][[BR]] 1*2*3 (*) 2 [][[BR]] 1*2*3*2[[BR]] 12[[BR]] Prelude>[[BR]] And to quit the mode we write from the prompt a command like this[[BR]] Prelude> :quitstp -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #229: Integer overflow in array allocation
by GHC 26 Dec '16

26 Dec '16

#229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ugh, yes, of course. Silly me. Fix coming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/229#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0