September 2013 - ghc-tickets

Re: [GHC] #3452: Show type of most recent expression in GHCi
by GHC 01 Sep '13

01 Sep '13

#3452: Show type of most recent expression in GHCi -------------------------------------+------------------------------------ Reporter: ozy | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 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 leroux): * cc: leroux@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3452#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3452: Show type of most recent expression in GHCi
by GHC 01 Sep '13

01 Sep '13

#3452: Show type of most recent expression in GHCi -------------------------------------+------------------------------------ Reporter: ozy | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 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 leroux): Instead of completely removing the following error. {{{ λ: id <interactive>:2:1: No instance for (Show (a0 -> a0)) arising from a use of `print' Possible fix: add an instance declaration for (Show (a0 -> a0)) In a stmt of an interactive GHCi command: print it }}} I think it would be saner and possibly better to just append the {{{:t}}} of {{{it}}} to the preceding error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3452#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

01 Sep '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): Have you tested `cabal -j` on this branch? They *should* compose fine, and I'd love to see what kind of speedup one can get installing the Haskell Platform packages. Unfortunately, right now I get a whole bunch of undefined reference errors when I try something like this: time cabal-1.18.0 install -j30 --disable-library-profiling --disable- documentation HUnit --reinstall Btw, I see the same problem with cabal 1.16.0.2. But taking away the -j30 makes it work. I do NOT have the same problem on master (8c99e698476291c) presently, nor on earlier versions of HEAD from 2013.08.04. (Yet, this might have nothing to do with parcs patches, of course. There are another ~46 patches that are on master but not on the `ghc-parmakegsoc` branch. Fast forwarding the branch will be my next step.) Notice that, weirdly, this problem occurs even when `ghc -j` is not used (as above). For reference here is a sample of the errors: {{{ cabal-1.17.0-HEAD-20130802: Error: some packages failed to install: HUnit-1.2.5.2 failed during the configure step. The exception was: user error (/home/beehive/ryan_scratch/ghc-parGSOC2/libraries/Cabal/Cabal/dist- install/build/libHSCabal-1.18.0.a(Simple__64.o): In function `chbT_info': (.text+0x857): undefined reference to `rff5_info' /home/beehive/ryan_scratch/ghc-parGSOC2/libraries/Cabal/Cabal/dist- install/build/libHSCabal-1.18.0.a(Simple__64.o): In function `sg4L_info': ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

01 Sep '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: -------------------------------------+------------------------------------ Changes (by akio): * cc: tkn.akio@… (added) Comment: #8209 might be related to the {{{setNumCapabilities}}} issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7327: Inconsistent behavior for relative paths in runProcess
by GHC 01 Sep '13

01 Sep '13

#7327: Inconsistent behavior for relative paths in runProcess --------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/process | Version: 7.6.1 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Blaisorblade): `runProcess` behavior is however still undocumented: http://hackage.haskell.org/packages/archive/process/latest/doc/html /System-Process.html#v:runProcess — should I open another bug for that? We're still observing symptoms, but the behavior might have been fixed in recent versions of libraries for Linux (different Linux machines, with different library versions, show different behavior in https://github.com/haskell/cabal/issues/1458#issuecomment-23616162) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7327#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 01 Sep '13

01 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: leroux Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by leroux): My fix is to simply apply a mask of n-bits to the word being passed to the fast population count function. After fixing the {{{popcnt8}}} test, I found that {{{popcnt16}}} also had the same problem, so I ended up applying the fix to 8, 16 and 32 bit word tests. {{{ test_popCnt8 = test (popcntMask 8 popcnt8) (slowPopcnt . wordMask 8) test_popCnt16 = test (popcntMask 16 popcnt16) (slowPopcnt . wordMask 16) test_popCnt32 = test (popcntMask 32 popcnt32) (slowPopcnt . wordMask 32) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 01 Sep '13

01 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: leroux Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by leroux): * status: new => patch * testcase: => cgrun071 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 01 Sep '13

01 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: leroux Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by leroux): * owner: => leroux Comment: I've run into this same problem on OS X 10.8.4 x86_64. I dug into cgrun071 and found that it's a problem with {{{popcnt8}}}. Whenever {{{popcnt8}}} encounters very "large" numbers, it segaults. {{{ map (\x -> (x, popcnt8 x)) $ iterate (+1000) 1 }}} I ran this expression multiple times expecting it to segfault at the same point, but it did otherwise. Whenever it broke, I tested the integer and it would simply segfault. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0