February 2015 - ghc-tickets

Re: [GHC] #4372: Extending quasiquotation support
by GHC 26 Feb '15

26 Feb '15

#4372: Extending quasiquotation support -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm not against this if someone wants to * Write a wiki page explaining the feature * Drive a discussion to refine any corners of the design; it's mainly a syntax question I think. * Implement a patch on Phabricator; including user manual documentation and some tests. > Another problem is that I suppose that the 4 quoters t, p, e, d are implemented in the layer of syntax I'm afraid I did not understand this part of your comment. Maybe it's a separate issue? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4372#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4316: Interactive "do" notation in GHCi
by GHC 26 Feb '15

26 Feb '15

#4316: Interactive "do" notation in GHCi -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 4459 | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by yokto): * cc: yokto (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4316#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 25 Feb '15

25 Feb '15

#7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie * component: Compiler => Compiler (Type checker) * milestone: => 7.12.1 Comment: More bugs. GHC only rejects the following program when `-XConstrainedClassMethods` is turned on. It should however always reject it, because `op` doesn't mention any type variables of `Foo`. {{{#!hs module ShouldFail where class Foo a where op :: Eq a => Int }}} I'm working on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4861: Documentation for base does not include special items
by GHC 24 Feb '15

24 Feb '15

#4861: Documentation for base does not include special items -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: ekmett Type: bug | Status: upstream Priority: low | Milestone: ⊥ Component: Core Libraries | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * milestone: 7.12.1 => ⊥ Comment: Deferring to _|_ as there doesn't appear to be any great desire on the part of the `haddock` folks to change this behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4861#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8189: Default to infinite stack size?
by GHC 24 Feb '15

24 Feb '15

#8189: Default to infinite stack size? ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- http://www.haskell.org/pipermail/haskell-cafe/2013-August/108570.html It looks like any code of the form {{{ ... = do x1 <- m1 x2 <- m2 [do something with x1 and m2] }}} will stack overflow when used with a strict monad (like IO) and sufficiently large data to deal with (a 1m element list is enough to exceed the default 8MB stack size limit). Other examples include: {{{ sequence (m:ms) = do x <- m xs <- sequence ms return (x:xs) }}} and {{{ liftM2, liftM3, ... }}} By slightly modifying your program to do the same thing via heap allocation (e.g. using a difference list in sequence), a stack-overflow rejected program turns into a valid program. This means that valid and idiomatic code like {{{ xs <- replicateM n someIOAction xs <- mapM someIOAction [1..n] }}} will eventually crash, which has an impact on practically all Haskell software and libraries out there. For examples, see https://github.com/ndmitchell/shake/blob/e0e0a43/Development/Shake/Database… https://github.com/haskell-suite/haskell-src-exts/issues/27 as well as the mapM usages in cabal, haddock, any database binding that allows querying a lists of results, etc. While some argue that ''"you shouldn't use lists of that size"'', ''"allocating a 150 MB list is wrong"'' or that they ''"carefully avoid any use of sequence/mapM due to the problem"'' pointed out above, I think that collecting a million results of a strict monadic action into a linked list using standard functions like mapM is a common pattern and valid use case. The stack based evaluation that GHC performs is an optimization and should be transparent to the user; it should not re-define some data to live in a fixed-size memory region, and it should work just as well as it does in GHCi. It seems that a default infinite stack size would mitigate this. A drawback might be that the stack space overflows we get so far to quickly spot a "wrong" program would not indicate certain errors any more. I currently doubt the usefulness of this debugging method, since it does not work reliably in the presence of optimization, doing the same thing via heap allocation makes the programs "correct", and it rejects valid programs if the input data is large enough. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

Re: [GHC] #7634: MD5 collision could lead to SafeHaskell violation
by GHC 24 Feb '15

24 Feb '15

#7634: MD5 collision could lead to SafeHaskell violation -------------------------------------+------------------------------------- Reporter: shachaf | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): Pretty much. There are also dozens if not hundreds of SHA-256 implementations out there in C we could take in more or less unmodified. Heck, I've even written one before, back in my crypto days. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7634#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7634: MD5 collision could lead to SafeHaskell violation
by GHC 24 Feb '15

24 Feb '15

#7634: MD5 collision could lead to SafeHaskell violation -------------------------------------+------------------------------------- Reporter: shachaf | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bananu7): A quick investigation shows that there are two parts of the problem: * `Fingerprint` is made of two `Word64`s; would need to change to four, and all the functions that manipulate on it to take four parts into account; that's an easy part * MD5 implementation used internally for hashing is written in C. I suppose the SHA-256 implementation that's necessary for the patch ''could'' be taken from `cryptohash` library, which seems pretty mature already. It would need to be integrated as a C source similarly to MD5; It's probably not feasible to drag the whole library as a GHC dependency; maybe I'm wrong here. Then the functions that have to be altered are `fingerprintData` and `fingerprintString`, the latter needing just to take the larger size of the fingerprint into the account, and the former actually being changed to use the SHA-256 context and hashing function. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7634#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 23 Feb '15

23 Feb '15

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 23 Feb '15

23 Feb '15

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:9 simonpj]: > 2. Only one field with nonzero width in that constructor (counting constraints as fields) I'd like to point out (as may already have been indented), that read literally, this should include things like {{{ data Dict :: Constraint -> * where Dict :: a => Dict a }}} from the `constraints` package. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10111: hp2ps silently discards samples
by GHC 23 Feb '15

23 Feb '15

#10111: hp2ps silently discards samples -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider the following hp file: {{{ JOB "whatever" DATE "Sat Feb 21 12:56 2015" SAMPLE_UNIT "seconds" VALUE_UNIT "bytes" BEGIN_SAMPLE 0.00 MAIN 1000 END_SAMPLE 0.00 BEGIN_SAMPLE 0.00 MAIN 100 END_SAMPLE 0.00 BEGIN_SAMPLE 0.01 MAIN 500 END_SAMPLE 0.01 }}} hp2ps will generate a graph showing heap usage going from 100 bytes to 500 bytes... not 1000-100-500 as expected. This is because hp2ps only uses the last sample with the same timestamp. These hp files show in practice because GHC doesn't output BEGIN_SAMPLE entries with enough precision, see also https://phabricator.haskell.org/D679 to increase the precision. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10111> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0