- ghc-tickets - Haskell.org

Re: [GHC] #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64#
by GHC 23 Oct '15

23 Oct '15

#4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# -------------------------------------+------------------------------------- Reporter: malosh | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: tkn.akio@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4092#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 23 Oct '15

23 Oct '15

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------- Reporter: quchen | Owner: quchen Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4834 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Replying to [comment:23 songzh]: > I am so curious that I want to ask for the case "You have an instance of Monad, but not Applicative" > why cann't we add default implementation to Applicative typeclass? > {{{ > class Functor f => Applicative f where > pure :: a -> f a > default pure :: Monad f => a -> f a > pure = return At least in the case of `pure` and `return` we have the default definition of `return` in terms of `pure`. That flow the 'right' way through the class hierarchy and doesn't require an extension. Doing both that and this yields a cycle with no way to detect it through `MINIMAL` pragmas and the like, which can't straddle two classes. > (<*>) :: f (a -> b) -> f a -> f b > default (<*>) :: Monad f => f (a -> b) -> f a -> f b > (<*>) f a = ap > }}} This one could be done. It'd require a willingness to have an attempt to implement `Applicative` that doesn't supply a `(<*>)` to be a compile error rather than a warning, however. (A state that can arise as you write incrementally.) It is a fairly minor concern, but given the difficulty of pushing through Prelude related changes one that __may__ be a sufficient blocker. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10987: -i option requires named module
by GHC 23 Oct '15

23 Oct '15

#10987: -i option requires named module -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the following layout: {{{ ./Foo.hs ./test/Bar.hs }}} both empty files. I can run ghci successfully as follows: {{{ >ghci Foo >ghci test/Bar >ghci -itest Foo }}} but {{{ >ghci -itest Bar File name does not match module name: Saw: ‘Main’ Expected: ‘Bar’ }}} The same problem occurs when `ghci` is replaced with `ghc`. Basically, ghc/ghci is forcing modules found via -i to have a named module in them. My understanding is that `ghci -itest Bar` is equivalent to `ghci test/Bar`, so the behavior should be the same as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10987> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11003: Suggested fix for incorrect directory permissions is wrong
by GHC 22 Oct '15

22 Oct '15

#11003: Suggested fix for incorrect directory permissions is wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If the current directory is group- or world- writable, I get an error {{{ *** WARNING: /home/blahblah/src/yproj is writable by someone else, IGNORING! Suggested fix: execute 'chmod 644 /home/blahblah/src/yproj' }}} This is extremely bad advice, because `644 = rw-r--r--`, meaning the directory is not executable, so nothing it contains can be accessed, and a user who's insufficiently familiar with Unix permissions will be very confused. The message should instead suggest `755=rwxr-xr-x`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10992: Performance regression
by GHC 22 Oct '15

22 Oct '15

#10992: Performance regression --------------------------------------+--------------------------------- Reporter: aleator | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: performane | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- For some reason Data.List.sum is much slower than the naive recursive definition for it. Does not seem happen in 7.8. {{{#!hs import Data.List import Criterion.Main sum1 [] = 0 sum1 (x:xs) = x + sum1 xs sum2 = foldr (+) 0 sum3 = foldl' (+) 0 sum4 = getSum #. foldMap Sum main = do let els = [1..100000] defaultMain [ bench "sum0" $ whnf (sum :: [Int] -> Int) els ,bench "sum" $ whnf (sum :: [Int] -> Int) els ,bench "sum1" $ whnf (sum1:: [Int] -> Int) els ,bench "sum2" $ whnf (sum2:: [Int] -> Int) els ,bench "sum3" $ whnf (sum3:: [Int] -> Int) els ,bench "sum4" $ whnf (sum4:: [Int] -> Int) els ] {- benchmarking sum0 time 128.0 ms (121.7 ms .. 133.8 ms) 0.997 R² (0.994 R² .. 1.000 R²) mean 132.8 ms (130.1 ms .. 136.3 ms) std dev 4.622 ms (2.980 ms .. 6.577 ms) variance introduced by outliers: 11% (moderately inflated) benchmarking sum time 131.0 ms (125.7 ms .. 136.7 ms) 0.998 R² (0.993 R² .. 1.000 R²) mean 131.9 ms (128.6 ms .. 136.7 ms) std dev 5.971 ms (2.903 ms .. 9.649 ms) variance introduced by outliers: 11% (moderately inflated) benchmarking sum1 time 26.29 ms (25.43 ms .. 27.24 ms) 0.995 R² (0.991 R² .. 0.998 R²) mean 26.30 ms (25.73 ms .. 26.98 ms) std dev 1.293 ms (953.2 μs .. 1.804 ms) variance introduced by outliers: 15% (moderately inflated) benchmarking sum2 time 26.39 ms (25.49 ms .. 27.26 ms) 0.995 R² (0.991 R² .. 0.998 R²) mean 26.33 ms (25.77 ms .. 26.95 ms) std dev 1.295 ms (941.5 μs .. 1.878 ms) variance introduced by outliers: 15% (moderately inflated) benchmarking sum3 time 7.695 ms (7.670 ms .. 7.722 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 7.703 ms (7.691 ms .. 7.733 ms) std dev 51.21 μs (25.43 μs .. 99.41 μs) benchmarking sum4 time 26.29 ms (25.40 ms .. 27.21 ms) 0.995 R² (0.989 R² .. 0.998 R²) mean 26.36 ms (25.88 ms .. 27.08 ms) std dev 1.364 ms (954.5 μs .. 1.899 ms) variance introduced by outliers: 20% (moderately inflated) -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10992> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #3351: Generated ghc man page missing xrefs
by GHC 22 Oct '15

22 Oct '15

#3351: Generated ghc man page missing xrefs -------------------------------------+------------------------------------- Reporter: kaol | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 8.0.1 Component: Documentation | Version: 6.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Good enough, let's close this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3351#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3351: Generated ghc man page missing xrefs
by GHC 22 Oct '15

22 Oct '15

#3351: Generated ghc man page missing xrefs -------------------------------------+------------------------------------- Reporter: kaol | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Documentation | Version: 6.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Things are slightly better now since we generate the manpage via Sphinx, although there is still room for improvement. You now see something like this, {{{ -Wall enable almost all warnings (details in options-sanity) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3351#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11002: man page incomplete sentences
by GHC 22 Oct '15

22 Oct '15

#11002: man page incomplete sentences -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- man page multiple entries like this: {{{ Interactive mode - normally used by just running ghci; see for details. be much easier, and faster, than using make; see for details.. Evaluate expr; see for details. }}} `see ... for details` the dotted part is missing. Probably a bug in the man page generator? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11002> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4295: Review higher-rank and impredicative types
by GHC 22 Oct '15

22 Oct '15

#4295: Review higher-rank and impredicative types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: task | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 6.12.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): No I have not looked at this for ages. Impredicativity is simply not a supported feature at the moment. If things are passing, then let them pass. If you have to change expect_broken to pass, then put a comment in the .hs file to point to this ticket and say that it might be wobbly because of impredicativity. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4295#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 22 Oct '15

22 Oct '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, Wiki Page: | Phab:D1268 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"9cb192ce4b34a472041010df9c30f5d741eb0261/ghc" 9cb192ce/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9cb192ce4b34a472041010df9c30f5d741eb0261" Make stronglyConnCompFromEdgedVertices deterministic This makes it so the result of computing SCC's depends on the order the nodes were passed to it, but not on the order on the user provided key type. The key type is usually `Unique` which is known to be nondeterministic. Test Plan: `text` and `aeson` become deterministic after this ./validate Compare compile time for `text`: ``` $ cabal get text && cd text* && cabal sandbox init && cabal install --dependencies-only && time cabal build real 0m59.459s user 0m57.862s sys 0m1.185s $ cabal clean && time cabal build real 1m0.037s user 0m58.350s sys 0m1.199s $ cabal clean && time cabal build real 0m57.634s user 0m56.118s sys 0m1.202s $ cabal get text && cd text* && cabal sandbox init && cabal install --dependencies-only && time cabal build real 0m59.867s user 0m58.176s sys 0m1.188s $ cabal clean && time cabal build real 1m0.157s user 0m58.622s sys 0m1.177s $ cabal clean && time cabal build real 1m0.950s user 0m59.397s sys 0m1.083s ``` Reviewers: ezyang, simonmar, austin, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1268 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0