June 2014 - ghc-tickets

[GHC] #8899: StdGen does not generate 0
by GHC 17 Sep '14

17 Sep '14

#8899: StdGen does not generate 0 ------------------------------------+------------------------------------- Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `genRange` for `StdGen` returns `(0,2147483562)`. However, as far as I can tell, `StdGen` doesn't generate 0. This code performs 200 billion iterations of `next` on a `StdGen`. I ran it and it output `Nothing`. The probability that no 0 was generated by chance is approximately ''e^-200/2.147^'' =~ ''10^-40^''. {{{#!haskell import System.Random import Data.Int find0 :: StdGen -> Int64 -> Maybe Int64 find0 g0 n0 = aux g0 n0 where aux _ 0 = Nothing aux g r = let (v,g') = next g in if v == 0 then Just (n0 - r + 1) else aux g' (r-1) main :: IO () main = print $ find0 (mkStdGen 1234) 200000000000 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8899> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8052: make ghci look for the files made by -dynamic-too
by GHC 03 Sep '14

03 Sep '14

#8052: make ghci look for the files made by -dynamic-too -----------------------------------+--------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+--------------------------------- If I compile with `-dynamic-too`, ghci still re-interprets the source code instead of finding the `Test.dyn_o` file. {{{ $ inplace/bin/ghc-stage2 -O1 -dynamic-too -c Test.hs $ inplace/bin/ghc-stage2 --interactive Test GHCi, version 7.7.20130710: 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 1] Compiling Test ( Test.hs, interpreted ) Ok, modules loaded: Test. *Test> }}} I'm guessing that ghci sees the `.o` file isn't suitable for dynamic loading and then falls-back to the interpreter without first checking for the `.dyn_o` file. ghci loads `Test.o` as expected if I instead compile with `-dynamic`. I'm on OS X 64-bit, if that might matter. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8886: sync-all: END actions result in confusing error message
by GHC 01 Sep '14

01 Sep '14

#8886: sync-all: END actions result in confusing error message -------------------------------------+------------------------------------- Reporter: fw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The instructions at [wiki:Newcomers] were slightly outdated, and result in a rather confusing error message: {{{ $ ./sync-all --testsuite get Unrecognised flag: --testsuite at ./sync-all line 872. == Checking for old haddock repo == Checking for old binary repo == Checking for old mtl repo == Checking for old Cabal repo == Checking for old time from tarball ============================ ATTENTION! You have an old time package in your GHC tree! Please remove it (e.g. "rm -r libraries/time"), and then run "./sync-all get" to get the new repository. ============================ == Checking for obsolete Git repo URL $ }}} The patch suppresses the misleading error message. I've already removed the `--testsuite` flag from the wiki page. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8886> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9212: Cleanup of sync-all
by GHC 01 Sep '14

01 Sep '14

#9212: Cleanup of sync-all ------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Some dead code removal and small bug fixes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9212> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8288: add idris style EDSL support for deep embedding lambdas
by GHC 27 Aug '14

27 Aug '14

#8288: add idris style EDSL support for deep embedding lambdas ----------------------------------------------+---------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- I could be wrong, but I think this would actually make it much easier to write interesting EDSLs and have a native haskelly syntax. This would sort of be in the same vein as the recently requested applicative brackets idea, albeit a tad more going on . -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8288> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8857: Sparc needs to be on the NoSharedLibsPlatformList
by GHC 27 Aug '14

27 Aug '14

#8857: Sparc needs to be on the NoSharedLibsPlatformList -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: sparc | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I see build failures with GHC-7.8 RC2 on sparc: https://buildd.debian.org/status/logs.php?pkg=ghc&ver=7.8.20140228-1&arch=s… These go away if I apply this patch, as suggested by Karel Gardas: {{{ Index: ghc-7.8.20140228/mk/config.mk.in =================================================================== --- ghc-7.8.20140228.orig/mk/config.mk.in 2014-03-06 09:48:52.000000000 +0000 +++ ghc-7.8.20140228/mk/config.mk.in 2014-03-06 09:49:55.000000000 +0000 @@ -98,7 +98,8 @@ NoSharedLibsPlatformList = arm-unknown-linux \ powerpc-unknown-linux \ x86_64-unknown-mingw32 \ - i386-unknown-mingw32 + i386-unknown-mingw32 \ + sparc-unknown-linux ifeq "$(SOLARIS_BROKEN_SHLD)" "YES" NoSharedLibsPlatformList += i386-unknown-solaris2 }}} Please consider applying this fix before next RC or the final release. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8857> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now.
by GHC 25 Aug '14

25 Aug '14

#8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: implicit- | Operating System: Unknown/Multiple parameter instance-constraints | Type of failure: Documentation Architecture: Unknown/Multiple | bug Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/other-type- extensions.html#implicit-parameters says: You can't have an implicit parameter in the context of a class or instance declaration. For example, both these declarations are illegal: {{{ class (?x::Int) => C a where ... instance (?x::a) => Foo [a] where ... }}} However, ghc 7.6.3 seems to accept this now: {{{ {-# LANGUAGE ImplicitParams #-} class C a where toInt :: a -> Int instance (?imp :: Int) => C [a] where toInt _ = ?imp test :: Int test = let ?imp = 5 in toInt "Hello, world" }}} test evaluates to 5. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8912> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9140: Unboxed tuples fails in GHCi (7.8.2)
by GHC 20 Aug '14

20 Aug '14

#9140: Unboxed tuples fails in GHCi (7.8.2) ------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Creating an unboxed tuple in GHCi causes panic: {{{ ➜ ~ ghci -XUnboxedTuples GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. ghci> let a = (# 1 #) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): dsLet: unlifted AbsBinds [a{tv auv} [tv]] [$dNum_auw{v} [lid]] {Exports: [a{v asV} [lid] <= a{v asY} [lid] /\(@ a{tv auy} [tv]). \($dNum_auz{v} [lid] :: base:GHC.Num.Num{tc 2b} a{tv auy} [tv]). let {EvBinds{$dNum_auC{v} [lid] = $dNum_auz{v} [lid]}} (<>) @ a{tv auy} [tv] $dNum_auC{v} [lid]] Exported types: a{v asV} [lid] :: forall a{tv auv} [tv]. base:GHC.Num.Num{tc 2b} a{tv auv} [tv] => (# a{tv auv} [tv] #) [LclId, Str=DmdType] Binds: {<interactive>:2:5-15} a{v asY} [lid] :: (# a{tv auv} [tv] #) [LclId, Str=DmdType] a{v asY} = {<interactive>:2:9-15} (# 1 ((base:GHC.Num.fromInteger{v 02A}) @ a{tv auv} [tv] $dNum_au8{v} [lid] 1) #) <> Evidence: EvBinds{$dNum_au8{v} [lid] = $dNum_auw{v} [lid]}} base:GHC.Base.returnIO{v 0z} [gid] @ [()] (ghc-prim:GHC.Types.:{(w) v 65} [gid[DataCon]] @ () (ghc-prim:GHC.Prim.unsafeCoerce#{(w) v 0u} [gid] @ (forall a{tv auv} [tv]. base:GHC.Num.Num{tc 2b} a{tv auv} [tv] => (# a{tv auv} [tv] #)) @ () a{v asV} [lid]) (ghc-prim:GHC.Types.[]{(w) v 6n} [gid[DataCon]] @ ())) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghci> let a = (# 1, 2 #) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): dsLet: unlifted AbsBinds [a{tv auW} [tv], a{tv auX} [tv]] [$dNum_auY{v} [lid], $dNum_auZ{v} [lid]] {Exports: [a{v auK} [lid] <= a{v auN} [lid] /\(@ a{tv av1} [tv]). /\(@ a{tv av2} [tv]). \($dNum_av3{v} [lid] :: base:GHC.Num.Num{tc 2b} a{tv av2} [tv]). \($dNum_av4{v} [lid] :: base:GHC.Num.Num{tc 2b} a{tv av1} [tv]). let {EvBinds{$dNum_av8{v} [lid] = $dNum_av3{v} [lid] $dNum_av9{v} [lid] = $dNum_av4{v} [lid]}} (<>) @ a{tv av1} [tv] @ a{tv av2} [tv] $dNum_av8{v} [lid] $dNum_av9{v} [lid]] Exported types: a{v auK} [lid] :: forall a{tv auW} [tv] a{tv auX} [tv]. (base:GHC.Num.Num{tc 2b} a{tv auX} [tv], base:GHC.Num.Num{tc 2b} a{tv auW} [tv]) => (# a{tv auW} [tv], a{tv auX} [tv] #) [LclId, Str=DmdType] Binds: {<interactive>:3:5-18} a{v auN} [lid] :: (# a{tv auW} [tv], a{tv auX} [tv] #) [LclId, Str=DmdType] a{v auN} = {<interactive>:3:9-18} (# 1 ((base:GHC.Num.fromInteger{v 02A}) @ a{tv auW} [tv] $dNum_auR{v} [lid] 1), 2 ((base:GHC.Num.fromInteger{v 02A}) @ a{tv auX} [tv] $dNum_auT{v} [lid] 2) #) <> Evidence: EvBinds{$dNum_auR{v} [lid] = $dNum_auZ{v} [lid] $dNum_auT{v} [lid] = $dNum_auY{v} [lid]}} base:GHC.Base.returnIO{v 0z} [gid] @ [()] (ghc-prim:GHC.Types.:{(w) v 65} [gid[DataCon]] @ () (ghc-prim:GHC.Prim.unsafeCoerce#{(w) v 0u} [gid] @ (forall a{tv auW} [tv] a{tv auX} [tv]. (base:GHC.Num.Num{tc 2b} a{tv auX} [tv], base:GHC.Num.Num{tc 2b} a{tv auW} [tv]) => (# a{tv auW} [tv], a{tv auX} [tv] #)) @ () a{v auK} [lid]) (ghc-prim:GHC.Types.[]{(w) v 6n} [gid[DataCon]] @ ())) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghci> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9140> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8712: Data.Ix missing info on row/column major indexing
by GHC 19 Aug '14

19 Aug '14

#8712: Data.Ix missing info on row/column major indexing -------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: row, column, | Operating System: Unknown/Multiple major, Ix | Type of failure: Documentation Architecture: Unknown/Multiple | bug Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- I've tried to use {{{Data.Ix}}} with {{{Data.Vector}}} for image manipulations and I confused column with row-major indexing. I expected than {{{Data.Ix.index ((0,0),(3,3)) (1,0) == 1}}} while it is actually equal to 4. Documentation for {{{Data.Ix}}} should explicitly state that it is row- major indexing and function {{{Data.Ix.index}}} might be accompanied by example like: {{{index ((0,0),(3,3)) (1,0) == 4}}} which should be obvious. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8712> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
by GHC 19 Aug '14

19 Aug '14

#8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) -------------------------------------------+------------------------------- Reporter: jimenezrick | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/unix | Version: 7.6.3 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- Discussion in the mailing list (I fixed both commented silly issues): http://www.haskell.org/pipermail/libraries/2013-December/021756.html Please review this pull request: https://github.com/jimenezrick/unix/compare/master...file-utils.patch If you find interesting this patch, then: git pull https://github.com/jimenezrick/unix.git file-utils -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8621> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6