October 2013 - ghc-tickets

Re: [GHC] #7767: "internal error: evacuate: strange closure type 154886248" crash
by GHC 07 Oct '13

07 Oct '13

#7767: "internal error: evacuate: strange closure type 154886248" crash -----------------------------------+---------------------------------- Reporter: rodlogic | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.2 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 schyler): * cc: simonmar (added) * type: feature request => bug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7767#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8297: Allow implicit parameters to take a default value
by GHC 07 Oct '13

07 Oct '13

#8297: Allow implicit parameters to take a default value ----------------------------------------------+---------------------------- 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: ----------------------------------------------+---------------------------- -XImplicitParams is not that useful except as a type hole. I had an idea where they could be adjusted to be really useful. Consider a function `primes` which uses a wheel sieve. {{{ -- primes: takes a size of the wheel to use, returns a lazy list of primes primes :: Int -> [Int] }}} Your average Joe may not be concerned about the technical details of this function. Why should he have to bother giving a wheel size? The function documentation might say `6` is a good value, but what if some research is done in the future and the library maintainer changes it, later deciding `7` is better? Joe wants to trust the library maintainer, but doesn't want to be burdened by maintaining this arbitrary constant in his code, nor does he like having to pass another parameter to primes. The type of `primes` could be implemented using an implicit parameter like this: {{{ primes -- returns an infinite list of primes primes :: (?wheelSize :: Int) -> [Int] }}} Joe still has to provide a wheelSize however, and now it's even more verbose than before. Wouldn't it be nice if the person who wrote the function could define a default value for `wheelSize`? Joe could use `primes` by itself in his code, whereas Bob, who runs his code on a very powerful server, could tune the performance of his sieve manually by explicitly using `primes where wheelSize = 100`. My suggestion is to develop a syntax which allows functions to define ''default'' values for their implicit parameters. I'm sure the community would have some fun coming up with creative uses for this in their libraries! As an extreme situation, consider the below example; {{{ -- takes a foo, bar, alpha, beta, gamma and epsilon for performance tuning. ouch. aVeryComplexSieveEx :: Int -> Int -> Int -> Int -> Int ... -> r -- f $ aVeryComplexSieveEx 1 2 3 4 ... aVeryComplexSieveEx :: SomeCompulsaryRecordConstructor -> Int -> r -- f $ aVeryComplexSieveEx (SomeCompulsaryRecordConstructor { ... }) 3 }}} vs {{{ aVeryComplexSieveEx :: (?foo :: Int, ?bar :: Int, ?alpha :: Int, ?beta :: Int, ?gamma :: Int) -> Int -> r -- f $ let ?alpha = 1337 in aVeryComplexSieveEx 3 }}} As you can see it would be beneficial for libraries to expose *optional* ways for users to tune internal values in this manner, without having to pass record constructors with many options or make new functions with tiresome numbers of parameters. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8297> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 06 Oct '13

06 Oct '13

#7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by ezyang): I must admit, I'm surprised that passing the thread-local state as a variable is not good performance-wise. At least within a function like evacuate, where everything ends up getting inlined into one giant function body, register pressure on x86_64 is low enough that I have seen (experimentally) that GCC is able to arrange for an extra parameter to not get spilled. Perhaps the situation is not so good across function call boundaries, but I don't see why it should necessarily be a problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7374: rule not firing
by GHC 06 Oct '13

06 Oct '13

#7374: rule not firing -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: bug | 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: -------------------------------------+------------------------------------ Comment (by nomeata): Looking at these many reports about rules not firing (e.g. #7398) due to other stuff happening earlier I wonder: Can’t we have a round of applying rules very early, before any inlining? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7374#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7685: :script command does not resolve ~
by GHC 06 Oct '13

06 Oct '13

#7685: :script command does not resolve ~ -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.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 nomeata): * cc: hvr (added) * status: new => patch Comment: Fix was easy; please merge from branch `WIP/T7685` or tell me to go ahead: http://git.haskell.org/ghc.git/commit/181975b01c1c84f22700e0e1ee64b9124b60c… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7685#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7650: can't use combining characters in identifiers
by GHC 06 Oct '13

06 Oct '13

#7650: can't use combining characters in identifiers ---------------------------------+--------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by nomeata): GHC already uses alex-3.1.0; that alone did not fix it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7650#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7593: Unable to print exceptions of unicode identifiers
by GHC 06 Oct '13

06 Oct '13

#7593: Unable to print exceptions of unicode identifiers -------------------------------------------------+------------------------- Reporter: dagit | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): Just FTR: It works with 7.6.1 on Linux, so the `Windows` attribute seems to be correct. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7593#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented
by GHC 06 Oct '13

06 Oct '13

#7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented -------------------------------+--------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+--------------------------- Changes (by nomeata): * cc: hvr (added) Comment: There is a related ticket/patch at #8380. Colin, what do you say to [ticket:8380#comment:4]? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7794#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4135: Can't Quote Instance Associated Types in Template Haskell
by GHC 06 Oct '13

06 Oct '13

#4135: Can't Quote Instance Associated Types in Template Haskell ----------------------------------------------+---------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Template Haskell | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects valid program | (amd64) Test Case: th/T4135 | Difficulty: Unknown Blocking: | Blocked By: 4230 | Related Tickets: ----------------------------------------------+---------------------------- Comment (by shelarcy): Replying to [comment:15 monoidal]: I see. I missed that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4135#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8413: testsuite: Allow to skip performance tests
by GHC 06 Oct '13

06 Oct '13

#8413: testsuite: Allow to skip performance tests ------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Test Suite | 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: | ------------------------------------+------------------------------------- More often than not the output of the performance tests is in the way, rather than helping, or simply not relevant at a certain time of development (e.g. after changing some error message generating code in the compiler). It would be nice to have a way to skip such tests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8413> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5