December 2014 - ghc-tickets

[GHC] #9866: ssh pubkey self-mgmt
by GHC 05 Dec '14

05 Dec '14

#9866: ssh pubkey self-mgmt -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Trac & Git | Version: Keywords: git | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9866> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7736: Parallel array enumeration causes compiler panic (enumFromToP)
by GHC 05 Dec '14

05 Dec '14

#7736: Parallel array enumeration causes compiler panic (enumFromToP) -------------------------------------+------------------------------------- Reporter: | Owner: chak amosrobinson | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #7078 time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by amosrobinson): * status: new => closed * resolution: => wontfix Comment: I don't think this is worth fixing - DPH hasn't been actively developed for a while, and the general impression is that it's too lofty a goal for now. As far as I know, this extension is only used by DPH? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7736#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5443: Errors when shutting down the event manager loop
by GHC 04 Dec '14

04 Dec '14

#5443: Errors when shutting down the event manager loop -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: tibbe Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 Resolution: worksforme | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5443#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9864: Need realloc/resize feature for mallocForeignPtrBytes allocated memory
by GHC 04 Dec '14

04 Dec '14

#9864: Need realloc/resize feature for mallocForeignPtrBytes allocated memory -------------------------------------+------------------------------------- Reporter: slomo | Owner: ekmett Type: feature request | Status: new Priority: low | Milestone: Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hi, it would be great if there would be something to reallocate or resize the memory allocated by - mallocPlainForeignPtrBytes or - mallocForeignPtrBytes Currently this is only possible with memory allocated via mallocBytes by using reallocBytes, but that's using the system's normal malloc()/realloc() and will not return memory in the GC heap. My proposal for a reallocForeignPtrBytes would have the same effects as reallocBytes. I.e. - if the new size is bigger than the old size, make enough free space available. This probably might result in copying the previous memory area to a newly allocated one - if the new size is smaller than the old size, mark mark the memory area as smaller. It should not result in immediate copying of the data, but it would e.g. allow the GC during a compacting phase to release the additional memory (note: I don't know how the GHC GC works internally) - if the new size is the same, do nothing One possible use case for this would be in ByteString. Currently Data.ByteString.Internal.createAndTrim will copy the completely memory if the actual size was less than the expected maximum size. This should be unnecessary and only wastes CPU cycles. It would also be useful for bindings to native libraries, e.g. for allocating the output buffer for iconv(). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9864> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2625: Unexpected -ddump-simpl output for derived Ord instance and UNPACKed fields
by GHC 04 Dec '14

04 Dec '14

#2625: Unexpected -ddump-simpl output for derived Ord instance and UNPACKed fields -------------------------------------+------------------------------------- Reporter: aslatter | Owner: Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => Runtime performance bug Comment: Since 7.8, setting `-fmax-worker-args=20` (higher than 16), as suggested by Simon in comment:3, doesn't have any effect on the core of the program from the description. It did in 7.6 and below. I can't tell whether the bug is fixed or not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2625#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 04 Dec '14

04 Dec '14

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation Operating System: Linux | fault, segfault, long input Type of failure: Runtime | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rafael-felix): Would it help to create a "should fail" test case inside the array directory? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2836: Data.Typeable does not use qualified names
by GHC 04 Dec '14

04 Dec '14

#2836: Data.Typeable does not use qualified names -------------------------------------+------------------------------------- Reporter: guest | Owner: ekmett Type: feature | Status: closed request | Milestone: 7.10.1 Priority: lowest | Version: 6.10.1 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: Goodness knows when, but this seems fixed: `TyCon` really stores the three bits Simon suggests above. There is still one thing missing: keeping track of the type namespace vs. the data namespace. But that's another ticket (#9858), so I'm closing this one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2836#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2640: Treat -X flags consistently in GHCi
by GHC 04 Dec '14

04 Dec '14

#2640: Treat -X flags consistently in GHCi -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) * failure: => None/Unknown * component: Compiler => GHCi -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2640#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2697: bad testsuite results with ghc-6.10.0.20081007
by GHC 04 Dec '14

04 Dec '14

#2697: bad testsuite results with ghc-6.10.0.20081007 ---------------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.9 Resolution: wontfix | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * failure: => None/Unknown * resolution: => wontfix Comment: Please see #9389 for the current list of testsuite failures on OS X. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2697#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2721: Newtype deriving doesn't work with type families
by GHC 04 Dec '14

04 Dec '14

#2721: Newtype deriving doesn't work with type families -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.10.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | deriving/should_fail/T2721 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2721#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0