November 2013 - ghc-tickets

Re: [GHC] #2301: Proper handling of SIGINT/SIGQUIT
by GHC 20 Nov '13

20 Nov '13

#2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"1b1f18b89d23094f4411be534c493a0da8aeadb9/process"]: {{{ #!CommitTicketReference repository="process" revision="1b1f18b89d23094f4411be534c493a0da8aeadb9" Add tests for the delegated control-C handling (#2301) Authored-by: Duncan Coutts <duncan(a)well-typed.com> Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2301#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2301: Proper handling of SIGINT/SIGQUIT
by GHC 20 Nov '13

20 Nov '13

#2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"3d8f9bb7f84c1fbb5efa62dd46daae44110ddb18/process"]: {{{ #!CommitTicketReference repository="process" revision="3d8f9bb7f84c1fbb5efa62dd46daae44110ddb18" Rename runGenProcess_ and leave a deprecated stub At least Cabal was using runGenProcess_, and the previous patches addressing #2301 changed its type already. So this adds a deprecated stub with the original type and the real function gets to have a less odd name. Authored-by: Duncan Coutts <duncan(a)well-typed.com> Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2301#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2301: Proper handling of SIGINT/SIGQUIT
by GHC 20 Nov '13

20 Nov '13

#2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"a0467f3ee892f5843c1ba98bcb9630e1e5b4863b/process"]: {{{ #!CommitTicketReference repository="process" revision="a0467f3ee892f5843c1ba98bcb9630e1e5b4863b" Implement delegated control-C handling on Unix (#2301) This is a generalisation of the SIGINT-ignoring that system and rawSystem do, to allow it to be used via the general createProcess. For the gory details of SIGINT handling, see http://www.cons.org/cracauer/sigint.html We implement the 'WCE' method described there. That important feature was only available to system and rawSystem (mirroring the C system() behaviour). These functions are very limited and indeed deprecated, so we need this feature in general. In particular projects like Cabal are suffering because they cannot do this properly (or need horrible workarounds copy and pasting much of System.Process and using System.Process.Internals). The feature is available now via a new delegate_ctlc flag in the CreateProcess options record. The use of signal handlers is still a little hairy, but probably better than before (for situations where there were multiple concurrent calls to system/rawSystem). One thing to note is that waitForProcess and getProcessExitCode can now throw the UserInterrupt exception. This is all documented in the haddock docs (both a short description and also the excruciating details). Authored-by: Duncan Coutts <duncan(a)well-typed.com> Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2301#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6056: INLINABLE pragma prevents worker-wrapper to happen.
by GHC 20 Nov '13

20 Nov '13

#6056: INLINABLE pragma prevents worker-wrapper to happen. --------------------------------------------+------------------------------ Reporter: milan | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): I agree that it's surprising and undesirable. The reason it happens is this. GHC keeps an "`Unfolding` inside each `Id`: * For INLINEABLE things it is the original user-written RHS * For w/w'd things it is the wrapper function But there's only ''one'' `Unfolding` for each `Id`, so we have to choose. As you point out, that is a pity. Solution is probably to keep two unfoldings, in effect. Thanks for pointing this out so clearly. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6056#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5395: Context reduction stack overflow without undecidable instances
by GHC 20 Nov '13

20 Nov '13

#5395: Context reduction stack overflow without undecidable instances -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 Resolution: | Keywords: type family, Operating System: Unknown/Multiple | termination Type of failure: GHC rejects | Architecture: Unknown/Multiple valid program | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): BTW, the user guide still says the default is 20: http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/flag- reference.html#idp39856880 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5395#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5395: Context reduction stack overflow without undecidable instances
by GHC 20 Nov '13

20 Nov '13

#5395: Context reduction stack overflow without undecidable instances -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 Resolution: | Keywords: type family, Operating System: Unknown/Multiple | termination Type of failure: GHC rejects | Architecture: Unknown/Multiple valid program | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => new * difficulty: => Unknown * resolution: fixed => Comment: I am just implementing separate counters for type family applications and constraints solving. Should I change the constraint limit back to `20` then, and leave the type family application limit at `200`? Or even higher? (Reopening as some discussion is required.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5395#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8541: Coercible should be higher-kinded
by GHC 20 Nov '13

20 Nov '13

#8541: Coercible should be higher-kinded ------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Just discussed with SJP: The Coercible should be higher kinded, and it seems to be straight forward. Given {{{ data T f = T (f Int) newtype List a = [a] }}} we want to be able to derive {{{ Coercible (T (Either Int)) (T (Either Age)) Coercible (T List) (T []) }}} We now allow `Coercible` at a kind `* -> k`, with the following intuition: {{{ Coercible A B ⇐⇒ (forall a. Coercible (A a) (B a)) }}} Note that this is ok independent of the role of `A`’s parameter, as we are not modifying that parameter here. Allowing such constraints, we therefore, we need these constraints exist in theory (but are in fact generated on demand, so only those of the rind kindnessare visible to the constraint solver) for `Either` and `List`: {{{ instance (Coercible a b, Coercible c d) => Coercible (Either a c) (Either b d) -- old instance Coercible a b => Coercible (Either a) (Either b) -- new instance Coercible [a] b => Coercible (List a) b -- old instance Coercible b [a] => Coercible b (List a) -- old instance Coercible a b => Coercible (List a) (List b) -- old instance Coercible [] b => Coercible List b -- new instance Coercible b [] => Coercible b List -- new }}} This solves the cases above. It does not solve all cases, though. Consider {{{ newtype NT1 a = NT1 (a -> Int) newtype NT2 a = NT2 (a -> Int) }}} and we want to solve `Coercible (T NT1) (T NT2)`. Although, by the definition above, `Coercible NT1 NT2` should hold, such a coercion cannot be created (as far as I can see). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8541> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8065: Set trac up for multiple git repos
by GHC 20 Nov '13

20 Nov '13

#8065: Set trac up for multiple git repos ------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Set trac up for multiple git repos: http://trac-hacks.org/wiki/GitPlugin#Multi-RepositoryConfiguration -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8065> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] Batch modify: #8070, #8065, #8121, #8251
by GHC 20 Nov '13

20 Nov '13

Batch modification to #8070, #8065, #8121, #8251 by hvr: component to Trac & Git -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=8070%2C8065%2C8121%2C8251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8543: `Coercible` ought to work for recursive newtypes
by GHC 20 Nov '13

20 Nov '13

#8543: `Coercible` ought to work for recursive newtypes -------------------------------------------+------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #8503 | Test Case: | Blocking: -------------------------------------------+------------------------------- At least on a best-effort basis. The approach (developed by SPJ and me) is to A) Add a feature to the constraint solver to prevent recursive dictionaries for specially marked instances (for now only used for `Coercible`). Rationale: Such dictionaries (which are fine for most classes like `Show`) would make `coerce` diverge. Implementation: Use the depth counter and do not use lower depths to solver constraints with a higher depth. This is of course a very conservative approximation, but should be sufficient. B) Use the regular constraint depth bound to prevent looping at compile time. In order for that to be more useful, count constraint solving and type function resolving separately. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8543> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1