August 2013 - ghc-tickets

[GHC] #8191: Do not trim type environment when reporting type holes
by GHC 05 Sep '13

05 Sep '13

#8191: Do not trim type environment when reporting type holes ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- Andres writes: I've just started playing with `TypeHoles`. (I'm writing some Haskell course materials and would like to use them from the very beginning once they become available.) However, I must say that I don't understand the current notion of "relevance" that seems to determine whether local bindings are included or not. The current rule seems to be that bindings are included only if the intersection between the type variables their types involve and the type variables in the whole is non-empty. However, I think this is confusing. Let's look at a number of examples: {{{ > f1 :: Int -> Int -> Int > f1 x y = _ Found hole ‛_’ with type: Int In the expression: _ In an equation for ‛f1’: f1 x y = _ }}} No bindings are shown. {{{ > f2 :: a -> a -> a > f2 x y = _ Found hole ‛_’ with type: a Where: ‛a’ is a rigid type variable bound by the type signature for f2 :: a -> a -> a at List.hs:6:7 Relevant bindings include f2 :: a -> a -> a (bound at List.hs:7:1) x :: a (bound at List.hs:7:4) y :: a (bound at List.hs:7:6) In the expression: _ In an equation for ‛f2’: f2 x y = _ }}} Both `x` and `y` (and `f2`) are shown. Why should this be treated differently from `f1`? {{{ > f3 :: Int -> (Int -> a) -> a > f3 x y = _ Found hole ‛_’ with type: a Where: ‛a’ is a rigid type variable bound by the type signature for f3 :: Int -> (Int -> a) -> a at List.hs:9:7 Relevant bindings include f3 :: Int -> (Int -> a) -> a (bound at List.hs:10:1) y :: Int -> a (bound at List.hs:10:6) In the expression: _ In an equation for ‛f3’: f3 x y = _ }}} Here, `y` is shown, but `x` isn't, even though `y` has to be applied to an Int in order to produce an `a`. Of course, it's possible to obtain an `Int` from elsewhere ... {{{ f4 :: a -> (a -> b) -> b f4 x y = _ Found hole ‛_’ with type: b Where: ‛b’ is a rigid type variable bound by the type signature for f4 :: a -> (a -> b) -> b at List.hs:12:7 Relevant bindings include f4 :: a -> (a -> b) -> b (bound at List.hs:13:1) y :: a -> b (bound at List.hs:13:6) In the expression: _ In an equation for ‛f4’: f4 x y = _ }}} Again, only `y` is shown, and `x` isn't. But here, the only sane way of filling the hole is by applying `y` to `x`. Why is one more relevant than the other? {{{ f5 x y = _ Found hole ‛_’ with type: t2 Where: ‛t2’ is a rigid type variable bound by the inferred type of f5 :: t -> t1 -> t2 at List.hs:15:1 Relevant bindings include f5 :: t -> t1 -> t2 (bound at List.hs:15:1) In the expression: _ In an equation for ‛f5’: f5 x y = _ }}} Neither `x` and `y` are included without a type signature. Even though all of the above types are admissible, which would convince GHC that one or even all may be relevant. IMHO, this isn't worth it. It's a confusing rule. Just include all local bindings in the output, always. That's potentially verbose, but easy to understand. It's also potentially really helpful, because it trains beginning programmers to see what types local variables get, and it's a way to obtain complex types of locally bound variables for expert programmers. It's also much easier to explain. It should be easier to implement, too :) Could we please change it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8191> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8190: mention --show-options in --help
by GHC 04 Sep '13

04 Sep '13

#8190: mention --show-options in --help ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC head now has a --show-options flag, that lists all of the supported ghc options. maybe --help should mention this flag, and that every option is specified in the ghc manual? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8190> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8158: Replace IO manager's IntMap with a mutable hash table
by GHC 03 Sep '13

03 Sep '13

#8158: Replace IO manager's IntMap with a mutable hash table -------------------------------------------+------------------------------- Reporter: bos | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- I've written a patch that replaces the immutable !IntMap used by GHC.Event with a mutable hashtable, !IntTable. There's a standalone version of the new data structure, complete with !QuickCheck tests and benchmarks, [[https://github.com/bos/inttable|available on github]]. It's about 15x faster than !IntMap, and substantially simpler. In practice, this translates to a small but measurable improvement in throughput (and presumably latency). I see a 3% to 10% bump in requests handled per second by the tiny [[http://hackage.haskell.org/package/acme- http|acme-http http server]] when benchmarked using the [[https://github.com/lighttpd/weighttp|weighttp load tester]]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8158> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #8193: document :kind! in ghci built-in help
by GHC 03 Sep '13

03 Sep '13

#8193: document :kind! in ghci built-in help ------------------------------------+-------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- Patch attached. I have the wording as: {{{ :kind[!] <type> show the kind of <type> (!: also show the normalised type) }}} could use some tweaking perhaps. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8193> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 31 Aug '13

31 Aug '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: 8184 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rrnewton): Ok, I'm trying to get a decent set of libraries installed to test this well. The very first thing I cabal installed ('text') did get a small speedup. However, I'm also seeing some excessive system time. This may have nothing to do with the parallel make approach and just be a function of the new IO manager. In fact, if I understand the design, worker threads in this model should either be running or blocked on MVars. (That's good for avoiding wasted user time as well, unlike work-stealing which burns cycles looking for work.) I'm running on a 32-core Intel Westmere machine, using this command to install `text` version 0.11.3.1: {{{ time cabal install text --ghc-options="-j24" --reinstall }}} Notice that in this simple test I am relying on the `setNumCapabilities` behavior. Here are the times: {{{ * 1 thread: real 1m20.028s user 1m17.921s sys 0m1.768s * 2 threads: real 1m7.417s user 1m22.818s sys 0m14.891s * 4 threads: real 0m59.528s user 1m29.110s sys 0m37.981s * 8 threads: real 0m57.219s user 1m54.461s sys 1m31.703s * 16 threads: real 1m6.225s user 4m46.976s sys 3m32.661s * 24 threads: real 1m16.501s user 9m53.254s sys 6m3.375s * 31 threads: real 1m27.445s user 17m0.314s sys 8m0.175s }}} Well, it's nice that final sequential time is not much worse than the one- threaded time! Finally, here is the fingerprint: {{{ .|4880dfaeafec1fc65568a5445a70ec4286949123 ghc-tarballs|f190b3ce329422e13cbe1b5dad030058ca4bdda7 libffi-tarballs|a0088d1da0e171849ddb47a46c869856037a01d1 libraries/Cabal|9f374ab45e62924506b992db9157c970c7259a03 libraries/Win32|3da00d80f2fd7d1032e3530e1af1b39fba79aac3 libraries/array|b5779026c4d760cc380ef1fc18403534dced55c1 libraries/base|1b725f6ada6c4ddb011172408291a64498d199cb libraries/binary|2799c25d85b4627200f2e4dcb30d2128488780c3 libraries/bytestring|7d5b516ad0937b7cdc29798db33a37a598123b6c libraries/containers|154cd539a22e4d82ff56fec2d8ad38855f78513a libraries/deepseq|420507ea418db8664a79aedaa6588b772e8c97c6 libraries/directory|571f32b2a0af7404a8483af5b1791361c5528ab6 libraries/filepath|8d34f787e06bf3a1802992246785939901dec8aa libraries/ghc-prim|84fed8933a53cd15e39123a8a0067369c060e69e libraries/haskeline|40bcd6ac30577d1d240166674d1e328ac52c1fd5 libraries/haskell2010|1c055868f748acb2945cb5652b3fdea6226e8862 libraries/haskell98|40300d61f29aa8d9953079d14fb5b2f1e5e04184 libraries/hoopl|8e0ef3b7bf6d25919209f74d65c4a77c6689934d libraries/hpc|a7231c6727de54d17ce14b1286cfe88c4db95783 libraries/integer-gmp|cfcd248c0921aafe599c8547022686c5289bf743 libraries/integer-simple|5d9c6565550fb5c9c38f69475f52a2ba1d3edf98 libraries/old-locale|df98c76b078de507ba2f7f23d4473c0ea09d5686 libraries/old-time|7e0df2eb500ce4381725b868440fde04fa139956 libraries/pretty|0b8eada2d4d62dd09ee361d8b6ca9b13e6573202 libraries/primitive|c6b1e204f0f2a1a0d6cb1df35fa60762b2fe3cdc libraries/process|5d47829c123c10711d14dd089b4d8d65f8289f3b libraries/random|4b68afd3356674f12a67a4e381fa9becd704fab2 libraries/template-haskell|ec6d5a7c9b0c9e2fb1ce10d776cff74548e17981 libraries/terminfo|116d3ee6840d52bab69c880d775ae290a20d64bc libraries/time|d4f019b2c6a332be5443b5bf88d0c7fef91523c6 libraries/transformers|a59fb93860f84ccd44178dcbbb82cfea7e02cd07 libraries/unix|ffdb844069497b276a719b0c89be35bd18095f22 libraries/vector|f27156970d9480806a5defcfea5367187c2a6997 libraries/xhtml|fb9e0bbb69e15873682a9f25d39652099a3ccac1 testsuite|5cad49d42e434130671c3d14692d73d56253fab8 utils/haddock|90ad0ea538d2fafed2047de8414c55627b94e879 utils/hsc2hs|46abf34f337dbc5fa638f06912e34966a9d1a147 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 31 Aug '13

31 Aug '13

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------ Reporter: quchen | Owner: quchen Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 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 hvr): * cc: hvr (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8116: Segfault/panic of 32bit GHCi on Mac
by GHC 31 Aug '13

31 Aug '13

#8116: Segfault/panic of 32bit GHCi on Mac ------------------------------------+------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- 32bit GHCi on Mac causes segfault/panic: With GHC 7.6.3: {{{ > :m Data.Complex [Prelude Data.Complex] > ((-2) :+ 0)**(1.5 :+ 0) zsh: segmentation fault ghci }}} With GHC head: {{{ > :m Data.Complex > ((-2) :+ 0)**(1.5 :+ 0) ghc: panic! (the 'impossible' happened) (GHC version 7.7.20130805 for i386-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/k0/548g5xg90jjfbrj5j09nvwv80000gq/T/ghc124_0/ghc124_0.dylib, 9): Library not loaded: /Users/kazu/work/ghc/libraries/base/dist- install/build/libHSbase-4.7.0.0-ghc7.7.20130805.dylib Referenced from: /var/folders/k0/548g5xg90jjfbrj5j09nvwv80000gq/T/ghc124_0/ghc124_0.dylib Reason: image not found Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} 64bit GHCi does not cause this problem. Any GHCi on Linux and FreeBSD do not cause this problem. If the code is compiled with 32bit GHC on Mac, it works fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8116> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8195: Different floating point results with -msse2 on 32bit Linux
by GHC 31 Aug '13

31 Aug '13

#8195: Different floating point results with -msse2 on 32bit Linux --------------------------+------------------------------------------------ Reporter: | Owner: jstolarek | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: | Operating System: Linux Compiler (NCG) | Type of failure: None/Unknown Keywords: | Test Case: perf/should_run/Conversions Architecture: x86 | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I noticed strange behaviour of `Conversions` test on 32bit machines. Here's the code of this test: {{{ {-# LANGUAGE BangPatterns #-} -- | Tests that conversions between various primitive types (e.g. -- Word, Double, etc) doesn't allocate. module Main (main) where import Data.Word -- Repeatedly convert Words to Doubles loop :: Floating a => Word -> a loop n = go 0 0.0 where go i !acc | i < n = go (i+1) (acc + fromIntegral i) | otherwise = acc {-# SPECIALISE loop :: Word -> Float #-} {-# SPECIALISE loop :: Word -> Double #-} main :: IO () main = do print (loop 1000000 :: Float) print (loop 1000000 :: Double) }}} This test is expected to produce: {{{ [t-jastol@cam-05-unx : /5playpen/t-jastol/ghc-validate] inplace/bin/ghc- stage2 -O -fforce-recomp testsuite/tests/perf/should_run/Conversions.hs [1 of 1] Compiling Main ( testsuite/tests/perf/should_run/Conversions.hs, testsuite/tests/perf/should_run/Conversions.o ) Linking testsuite/tests/perf/should_run/Conversions ... [t-jastol@cam-05-unx : /5playpen/t-jastol/ghc-validate] ./testsuite/tests/perf/should_run/Conversions 4.9994036e11 4.999995e11 }}} My optimization of self-recursive tail loops (d61c3ac186c94021c851f7a2a6d20631e35fc1ba) broke that and now both `Float` and `Double` results are identical: {{{ 4.999995e11 4.999995e11 }}} I believe my optimisation shouldn't affect this, but clearly it does. Now here's the interesting part: if I generate SSE assembly by adding `-msse2` flag, then I get expected results: {{{ 4.9994036e11 4.999995e11 }}} I'm not sure if we should get different results for different instruction sets. I'm putting it up as a ticket so perhaps we could investigate this more one day if we consider it relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8195> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7751: Incremental heap census
by GHC 31 Aug '13

31 Aug '13

#7751: Incremental heap census -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * status: new => closed * resolution: => wontfix Comment: I'm working on a new implementation which eliminates my primary use-case for this feature; as such, I think this is something more of a theoretical curiosity; of course, if someone decides they need this feature, we can reconsider. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7751#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7399: Test Posix004 fails in test-suite
by GHC 31 Aug '13

31 Aug '13

#7399: Test Posix004 fails in test-suite ------------------------------------------------+-------------------------- Reporter: paulh | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/unix | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by ezyang): * status: merge => closed * resolution: => fixed Comment: Actually, it's just a test fix, no point merging. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7399#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0