April 2013 - ghc-tickets

Re: [GHC] #7345: unix-2.6.0.0 does not provide access to st_blksize and st_blocks
by GHC 12 Apr '13

12 Apr '13

#7345: unix-2.6.0.0 does not provide access to st_blksize and st_blocks -------------------------------+-------------------------------------------- Reporter: JohnWiegley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.1 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Thanks for the suggestion. However, library API changes need to be discussed on the libraries list first, and then a ticket opened once consensus is reached; please see http://www.haskell.org/haskellwiki/Library_submissions for details. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7345#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7337: GHC does not generate great code for bit-level rotation
by GHC 12 Apr '13

12 Apr '13

#7337: GHC does not generate great code for bit-level rotation ---------------------------------+------------------------------------------ Reporter: bos | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 7.8.1 Comment: Thanks for the report. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7337#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7335: Need for extra warning pragma for accidental pattern matching in do blocks
by GHC 12 Apr '13

12 Apr '13

#7335: Need for extra warning pragma for accidental pattern matching in do blocks ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 7.8.1 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7335#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7261: ghci's :info and :browse break encapsulation
by GHC 12 Apr '13

12 Apr '13

#7261: ghci's :info and :browse break encapsulation ---------------------------------+------------------------------------------ Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Other Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by Feuerbach): Sorry, I wasn't clear. I am puzzled by the fact that in a bare ghci session, without importing any additional modules except Prelude, 1) The type `IO` is available under the name `GHC.IO.IO` 2) The data constructor `GHC.IO.IO` is in scope In ordinary Haskell, you'd need to `import GHC.IO` for that to be the case. Hence my question. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7261#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7331: Allow the evaluation of declaration splices in GHCi
by GHC 12 Apr '13

12 Apr '13

#7331: Allow the evaluation of declaration splices in GHCi ---------------------------------+------------------------------------------ Reporter: parcs | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 7.8.1 Comment: Thanks for the suggestion. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7331#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7329: ghc-7.6.1 win64: internal error: R_X86_6 4_PC32: High bits are set in WSAGetLastError
by GHC 12 Apr '13

12 Apr '13

#7329: ghc-7.6.1 win64: internal error: R_X86_6 4_PC32: High bits are set in WSAGetLastError ---------------------------------+------------------------------------------ Reporter: dagit | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1 Keywords: | Os: Windows Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: 3658 | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * component: Compiler => GHCi * milestone: => 7.8.1 Comment: Thanks for the report. This will be fixed once GHCi is dynamic. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7329#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3658: Dynamically link GHCi (and use system linker) on platforms that support it
by GHC 12 Apr '13

12 Apr '13

#3658: Dynamically link GHCi (and use system linker) on platforms that support it ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.10.4 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: 5987 | Blocking: 781, 1883, 2283, 3242, 3333, 3372, 3654, 4244, 5062, 5197, 5435, 6107, 7043, 7056, 7072, 7097, 7103, 7134, 7329, 7475 Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * blocking: 781, 1883, 2283, 3242, 3333, 3372, 3654, 4244, 5062, 5197, 5435, 6107, 7043, 7056, 7072, 7097, 7103, 7134, 7475 => 781, 1883, 2283, 3242, 3333, 3372, 3654, 4244, 5062, 5197, 5435, 6107, 7043, 7056, 7072, 7097, 7103, 7134, 7329, 7475 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3658#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

12 Apr '13

#7327: Inconsistent behavior for relative paths in runProcess ----------------------------------+----------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: libraries/process | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => infoneeded * difficulty: => Unknown * milestone: => 7.8.1 Comment: I'm confused; this behaves the same on Linux and OS X for me: {{{ $ cat q.hs import System.Process main :: IO () main = do ph <- runProcess "./runme.sh" [] (Just "sub") Nothing Nothing Nothing Nothing ec <- waitForProcess ph print ec $ cat runme.sh #!/bin/sh echo Running root $ cat sub/runme.sh #!/bin/sh echo Running in sub $ ghc --make q $ ./q Running in sub ExitSuccess $ }}} Can you tell me how I can reproduce the problem, please? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7327#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7309: The Ix instance for (,) leaks space in range
by GHC 12 Apr '13

12 Apr '13

#7309: The Ix instance for (,) leaks space in range ----------------------------------+----------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries (other) | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------+----------------------------------------- Changes (by igloo): * milestone: => _|_ Comment: Milestone `_|_` to match #7206. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7309#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7309: The Ix instance for (,) leaks space in range
by GHC 12 Apr '13

12 Apr '13

#7309: The Ix instance for (,) leaks space in range ----------------------------------+----------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------+----------------------------------------- Description changed by igloo: Old description: > (at least if you take leak to mean unexpected space behaviour). > > This was brought to my attention via > http://stackoverflow.com/questions/12780497/puzzling-memory-behavior-in- > haskell where someone created a 6×10^6-array and was surprised that > showing the array caused an additional (3+2)*8*10^6 bytes to be used. The > reason (as far as I could tell) was this code: > > {{{ > instance (Ix a, Ix b) => Ix (a, b) where > range ((l1,l2),(u1,u2)) = [ (i1,i2) | i1 <- range (l1,u1), i2 <- > range (l2,u2) ] > }}} > in Arr.GHC. The result of {{{range (l2,u2)}}} is shared between every > step in the first component of the index. > > I guess it is reasonable to expect that the result of range is never > worth sharing (is it?). I am not entirely sure what the best, cleanest, > alternative implementation is, though. (At least not without a working > ```dontshare``` annotation ;-)) New description: (at least if you take leak to mean unexpected space behaviour). This was brought to my attention via http://stackoverflow.com/questions/12780497/puzzling-memory-behavior-in- haskell where someone created a `6×10^6`-array and was surprised that showing the array caused an additional `(3+2)*8*10^6` bytes to be used. The reason (as far as I could tell) was this code: {{{ instance (Ix a, Ix b) => Ix (a, b) where range ((l1,l2),(u1,u2)) = [ (i1,i2) | i1 <- range (l1,u1), i2 <- range (l2,u2) ] }}} in Arr.GHC. The result of {{{range (l2,u2)}}} is shared between every step in the first component of the index. I guess it is reasonable to expect that the result of range is never worth sharing (is it?). I am not entirely sure what the best, cleanest, alternative implementation is, though. (At least not without a working ```dontshare``` annotation ;-)) -- -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7309#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0