- ghc-tickets - Haskell.org

Re: [GHC] #7253: Top-level bindings in ghci
by GHC 22 Nov '15

22 Nov '15

#7253: Top-level bindings in ghci -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: roshats Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1299 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"b98ff3ccb14e36145404f075349c8689762a2913/ghc" b98ff3cc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b98ff3ccb14e36145404f075349c8689762a2913" Function definition in GHCi This patch allows define and re-define functions in ghci. `let` is not required anymore (but can be used). Idea: If ghci input string can be parsed as statement then run it as statement else run it as declaration. Reviewers: mpickering, bgamari, austin Reviewed By: mpickering, bgamari, austin Subscribers: hvr, mpickering, dterei, thomie Differential Revision: https://phabricator.haskell.org/D1299 GHC Trac Issues: #7253 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7253#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

22 Nov '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, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"2325bd4e0fad0e5872556c5a78d1a6a1873e7201/ghc" 2325bd4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2325bd4e0fad0e5872556c5a78d1a6a1873e7201" Create a deterministic version of tyVarsOfType I've run into situations where I need deterministic `tyVarsOfType` and this implementation achieves that and also brings an algorithmic improvement. Union of two `VarSet`s takes linear time the size of the sets and in the worst case we can have `n` unions of sets of sizes `(n-1, 1), (n-2, 1)...` making it quadratic. One reason why we need deterministic `tyVarsOfType` is in `abstractVars` in `SetLevels`. When we abstract type variables when floating we want them to be abstracted in deterministic order. Test Plan: harbormaster Reviewers: simonpj, goldfire, austin, hvr, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1468 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:132> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell
by GHC 21 Nov '15

21 Nov '15

#11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | 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 am writing a bit of TemplateHaskell for stringing together QuickCheck style specifications. I require every module containing properties to export a symbol called ''axiom_set''. Then, my checkAxioms function finds all the ''axiom_set'' symbols from modules imported where I call checkAxioms. checkAxioms :: DecsQ checkAxioms = do ModuleInfo ms <- reifyModule =<< thisModule forM_ ms $ \mi@(Module _ m) -> do runIO . print =<< lookupValueName (modString m ++ ".axiom_set") The above code should find all the imported "axiom_set" symbols. However, if Module.Axioms defines axiom_set but that I imported as follows import Module.Axioms as MA my code can't find MA.axiom_set. I think either modString should return MA in the case of Module.Axioms or there should be a function that takes a symbol and a module and constructs a Name referring to the symbol in the module and considering possible renamings of modules. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11078> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 21 Nov '15

21 Nov '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, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by niteria): * differential: Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192, Phab:D1268 => Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192, Phab:D1268, Phab:D1360, Phab:D1373, Phab:D1396, Phab:D1457, Phab:D1468, Phab:D1487, Phab:D1504, Phab:D1508 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11118: Very hard to load previously compiled .o files in ghci
by GHC 21 Nov '15

21 Nov '15

#11118: Very hard to load previously compiled .o files in ghci -------------------------------------+------------------------------------- Reporter: duncan | 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: -------------------------------------+------------------------------------- It's extremely hard to get ghci to load .o files created previously. The upshot is that cabal repl never loads previous .o files. It did used to be also to with older ghc versions. There is currently nothing sensible cabal can do about this except to build things twice (which isn't sensible). When one compiles modules using -static -dynamic-too, then ghci will not load those .o files, even if one specifies the appropriate -dynosuf -dynhisuf. One way to get ghci to load the .o files is if one does not build the static .o files at all, and only builds with -dynamic. This means the main .o files are the dynamic ones. It's possible to do this and keep the sets of files separate, by using -dynamic -osuf dyn_o -hisuf dyn_hi for --make mode, and then again for --interactive mode. However it's then impossible to use the -dynamic-too mode, which we want since it saves time. In this mode, although ghc does indeed generate dyn_o and dyn_hi files, ghci will not load these, even if one specifies -osuf dyn_o -hisuf dyn_hi. If one tries, ghci says "[flags changed]". So it looks like the problem is that the -static -dynamic-too information gets saved into the generated dyn_hi files. The info that should be saved probably should be as if they were generated with -dynamic only. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11116: GC reports memory in use way below the actual
by GHC 21 Nov '15

21 Nov '15

#11116: GC reports memory in use way below the actual -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | 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: -------------------------------------+------------------------------------- The following program encodes and decodes a long list of words. The memory in use reported by the GC seems to be off by multiple gigabytes when compared to the reports of the OS. Results shown below. ghc-7.10.2, binary-0.7.6.1. {{{ #!haskell import Control.Exception (evaluate) import Control.Monad (void) import Data.Binary (encode, decode) import qualified Data.ByteString.Lazy as BSL import Data.List (isPrefixOf, foldl') import Data.Word (Word32) import GHC.Stats import System.Mem (performGC) type T = (Word32,[Word32]) main :: IO () main = do let sz = 1024 * 1024 * 15 xs = [ (i,[i]) :: T | i <- [0 .. sz] ] bs = encode xs void $ evaluate $ sum' $ map (\(x, vs) -> x + sum' vs) xs putStrLn "After building the value to encode:" printMem putStrLn $ "Size of the encoded value: " ++ show (BSL.length bs `div` (1024 * 1024)) ++ " MB" putStrLn "" putStrLn "After encoding the value:" printMem let xs' = decode bs :: [T] void $ evaluate $ sum' $ map (\(x, vs) -> x + sum' vs) xs' putStrLn "After decoding the value:" printMem -- retain the original list so it is not GC'ed void $ evaluate $ last xs -- retain the decoded list so it is not GC'ed void $ evaluate $ last xs' printMem :: IO () printMem = do performGC readFile "/proc/self/status" >>= putStr . unlines . filter (\x -> any (`isPrefixOf` x) ["VmHWM", "VmRSS"]) . lines stats <- getGCStats putStrLn $ "In use according to GC stats: " ++ show (currentBytesUsed stats `div` (1024 * 1024)) ++ " MB" putStrLn $ "HWM according the GC stats: " ++ show (maxBytesUsed stats `div` (1024 * 1024)) ++ " MB" putStrLn "" sum' :: Num a => [a] -> a sum' = foldl' (+) 0 }}} Here are the results: {{{ # ghc --make -O -fno-cse -fforce-recomp -rtsopts test.hs # time ./test +RTS -T After building the value to encode: VmHWM: 2782700 kB VmRSS: 2782700 kB In use according to GC stats: 1320 MB HWM according the GC stats: 1320 MB Size of the encoded value: 240 MB After encoding the value: VmHWM: 3064976 kB VmRSS: 3064976 kB In use according to GC stats: 1560 MB HWM according the GC stats: 1560 MB After decoding the value: VmHWM: 7426784 kB VmRSS: 7426784 kB In use according to GC stats: 2880 MB HWM according the GC stats: 2880 MB real 0m24.348s user 0m22.316s sys 0m1.992s }}} At the end of the program the OS reports 7 GB while the GC reports less than 3G of memory in use. Running the program with {{{+RTS -M3G}}} keeps VmHWM bounded at the expense of doubling the execution time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11116> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11114: Can't compile ghc on fedora 23
by GHC 21 Nov '15

21 Nov '15

#11114: Can't compile ghc on fedora 23 -------------------------------------+------------------------------------- Reporter: waghanza | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, I' m trying to compile (through a ''Docker'' '''container''') ghc 7.10.2 My commands are: {{{ dnf -y install @development-tools @rpm-development-tools glibc-devel ncurses-devel gmp-devel autoconf automake libtool gcc make perl python ghc happy alex git python-sphinx git clone --recursive git://git.haskell.org/ghc.git /opt/ghc git checkout ghc-7.10.2-release ./boot ./configure --prefix=/usr/local make -j$((`grep -c processor /proc/cpuinfo`+1)) }}} The '''make''' process fails. Here is the stack => https://gist.github.com/anonymous/0800967ca05e5a2c65b8 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11115: Indicate missing associated type instances
by GHC 20 Nov '15

20 Nov '15

#11115: Indicate missing associated type instances -------------------------------------+------------------------------------- Reporter: rimmington | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | 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: -------------------------------------+------------------------------------- If there is no matching instance for a typeclass that defines an associated type, GHC cannot further reduce an application of that associated type. For nested type family applications, this produces rather large error messages, eg: {{{ <interactive>:98:20: Couldn't match type ‘units-2.3:Data.Metrology.Factor.Normalize (Data.Metrology.Suspicious.Poly.SurfaceUnitFactorsOf (Data.Singletons.Prelude.Tuple.Snd (Data.Metrology.Suspicious.Poly.SplitPrefix (PrefixExp Deci) Deci Core)) units-2.3:Data.Metrology.Factor.@- '['units-2.3:Data.Metrology.Factor.F Core ('Data.Metrology.Z.S 'Data.Metrology.Z.Zero)])’ with ‘'[]’ In the expression: (25 %> centi Core) `ceilToUnit` deci Core In an equation for ‘it’: it = (25 %> centi Core) `ceilToUnit` deci Core }}} The cause of the above error message is that `Deci` is not a member of the typeclass `ExpUnitPrefix` that defines the associated type `PrefixExp`. Unfortunately this is not clear at all from the error message, and adding additional class constraints to the appropriate functions doesn't improve things. It would be nice if GHC pointed out that there is no `ExpUnitPrefix Deci` instance, or at least that `PrefixExp Deci` cannot be further reduced. I imagine this would be useful for open type families as well, but I can't comment personally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11115> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide
by GHC 20 Nov '15

20 Nov '15

#10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 Documentation | Keywords: | Operating System: Unknown/Multiple PatternSynonms | Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I read the chapter on PatternSynonyms recently. Seems like a very useful feature! Here are my notes, in the same spirit as #10140. == 7.3.9 == * This section starts with a nice example of how pattern synonyms can make some code much clearer. No problems sofar. > Note that in this example, the pattern synonyms Int and Arrow can also be > used as expressions (they are bidirectional). * How can a pattern (synonym) possibly be used as an expression. They seem such different concepts. You say "bidirectional", but what are the directions? You mentioned "constructor-like" before, maybe it's something like that? * This could use an example. * Is `Arrow Int Int` an example of using a pattern synonym as an expression? * What about `pattern Maybe t`, can it also be used as an expression? Why is this not mentioned? What is it doing there anyway, it's not used in either of the functions `collectArgs`, `isInt` and `isIntEndo`. > This is not necessarily the case: unidirectional pattern synonyms can also be > declared with the following syntax * Ok. > We can give an explicit inversion of a pattern synonym using the > following syntax * What does inverting a pattern synonym mean? * You mentioned unidirectional and bidirectional pattern synonyms. Can I invert both? {{{ pattern Head x <- x:xs where Head x = [x] }}} * Weird syntax. But what does it //do//? (I'm very confused now) == 7.3.9.1 == > Either prefix or infix syntax can be used. * I have no idea what this refers to. > For implicitly bidirectional pattern synonyms * This is the first time you mention the word "implicit". > For unidirectional and explicitly-bidirectional pattern synonyms * Ok, now it's getting clear. There seem to be 3 types of pattern synonyms. I wish you had said this earlier. (goes back to read from the beginning: ok I guess the first time you mentioned bidirectional patttern synonyms, they were the implicit ones, and the "explicit inversion" stuff with the weird syntax are the explicit ones.) == 7.3.9.2 == {{{ import Data.Maybe( pattern Just ) }}} * This doesn't compile. It turns out I need the PatternSynonyms extension in the importing module, even though you said in the beginning "it is required for defining them, but //not// for using them". * I later found #10653, so that explains it. Maybe mention that ticket. == 7.3.9.3 == > In the common case where CReq is empty, (), it can be omitted altogether. * Why is it more common for CReq to empty than for CProv to be empty? * What if CProv is empty, but CReq isn't? * What if both are empty, can they both be omitted? > so function f is rejected because the type signature is Maybe a * I tried this example, and f is not rejected at all. **Bug**? == 7.3.9.4 == > A pattern synonym occurrence in a pattern is evaluated by first matching > against the pattern synonym itself, and then on the argument patterns. * Should be "against the //rhs// of the pattern synonym" I think. * This is tricky stuff. Why is pattern synonym semantics not just defined as 'textual substitution'? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10900> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] Batch modify: #11086, #11087, #11088, #11089, #11090
by GHC 20 Nov '15

20 Nov '15

Batch modification to #11086, #11087, #11088, #11089, #11090 by thomie: Action: resolve Comment: Duplicate of #11091, possibly from form resubmission. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=11086%2C11087%2C11088%2C11089%2C11…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0