- ghc-tickets - Haskell.org

[GHC] #9759: Add Alternative wrapper to Data.Monoid
by GHC 08 Nov '14

08 Nov '14

#9759: Add Alternative wrapper to Data.Monoid -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As discussed on the libraries list, {{{#!hs -- | Monoid under @<|>@. newtype Alt f a = Alt {getAlt :: f a} deriving (Generic, Generic1, Read, Show, Eq, Ord, Num, Enum, Monad, MonadPlus, Applicative, Alternative, Functor) instance forall f a . Alternative f => Monoid (Alt f a) where mempty = Alt empty mappend = coerce ((<|>) :: f a -> f a -> f a) }}} The documentation for `Data.Monoid.First` and `Data.Monoid.Last` should also be expanded to explain that `First a` is isomorphic to `Alt Maybe a` and `Last a` is isomorphic to `Dual (Alt Maybe a)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9759> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9742: The default definitions of foldl1 and foldr1 are too strict
by GHC 08 Nov '14

08 Nov '14

#9742: The default definitions of foldl1 and foldr1 are too strict -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- We currently have {{{#!hs foldr1 :: (a -> a -> a) -> t a -> a foldr1 f xs = fromMaybe (error "foldr1: empty structure") (foldr mf Nothing xs) where mf x Nothing = Just x mf x (Just y) = Just (f x y) }}} This has to traverse the entire list before it can do anything. What we want is {{{#!hs mf x r = Just $ case r of Nothing -> x Just y -> f x y }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8828: allow fully applied type families in instance heads
by GHC 08 Nov '14

08 Nov '14

#8828: allow fully applied type families in instance heads ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hi, it would be nice if the following example were acceptable: {{{ {-# LANGUAGE FlexibleInstances, TypeFamilies, TypeSynonymInstances #-} data X a = X a type family TX a type instance TX a = X a instance Show (TX Int) }}} But ghc complains that it cannot substitute the instance of TX: {{{ ts.hs:6:10: Illegal type synonym family application in instance: TX Int In the instance declaration for ‛Show (TX Int)’ }}} A more practical (but not self-contained) example involving extensible records looks http://lpaste.net/100436 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8828> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9295: Deadlock in forkProcess
by GHC 08 Nov '14

08 Nov '14

#9295: Deadlock in forkProcess ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As part of `forkProcess` we discard all tasks except the one task that remains. As part of this we call `freeTask`, and `freeTask` in turn calls `closeCondition` and `closeMutex`, which are very thin wrappers around `pthread_cond_destroy` and `phread_mutex_destroy`. However, the behaviour of these functions is undefined when there are currently threads blocked on these condition variables/mutexes. In reality, this undefined behaviour often (though not always) results in a deadlock. Unfortunately, I don't have a minimal test case to demonstrate this, but in the large system on which I am testing this I am seeing these deadlocks rather frequently. For the global mutex we don't attempt to call `pthread_cond_destroy` or `pthread_mutex_destroy`, but instead re-initialize them. The patch https://phabricator.haskell.org/D59 does precisely that for the condition variables and mutexes associated with tasks. This is ''somewhat'' or a long way around, because we will then subsequently still call `pthread_..._destroy`, but it means that we don't have to mess with `freeTask`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #2528: documentation for nub and nubBy should be corrected, extended or removed.
by GHC 08 Nov '14

08 Nov '14

#2528: documentation for nub and nubBy should be corrected, extended or removed. -------------------------------------+------------------------------------- Reporter: jdressel | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 6.8.2 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@… (added) * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2528#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7913: Argument order not preserved by nubBy
by GHC 08 Nov '14

08 Nov '14

#7913: Argument order not preserved by nubBy -------------------------------------+------------------------------------- Reporter: paullik | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Prelude | Version: 7.6.3 Resolution: fixed | Keywords: nubBy Operating System: Linux | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 7.10.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7913#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9296: Acquire all_tasks_mutex in forkProcess
by GHC 08 Nov '14

08 Nov '14

#9296: Acquire all_tasks_mutex in forkProcess ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In `forkProcess` we acquire a bunch of mutexes so make sure that when we fork the child doesn't see an inconsistent state of any global data structures. However, we do not acquire the `all_tasks_mutex`, which means that the child might have an inconsistent view of the `all_tasks` list. https://phabricator.haskell.org/D60 Sadly, I do not have a test case illustrating that this is in fact a problem. Found this while working tracking down a deadlock in forkProcess (https://ghc.haskell.org/trac/ghc/ticket/9295) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9296> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #2528: documentation for nub and nubBy should be corrected, extended or removed.
by GHC 08 Nov '14

08 Nov '14

#2528: documentation for nub and nubBy should be corrected, extended or removed. -----------------------------------+------------------------------------ Reporter: jdressel | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"a2e7bbfe7656cf7dbf1af4da5c077ac0b5d41127/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a2e7bbfe7656cf7dbf1af4da5c077ac0b5d41127" Preserve argument order to (==)/eq in nub and nubBy This makes nub and nubBy behave as specified in the Haskell 98 Report. This reverts 0ad9def53842e86fb292eccb810190711c42d7c5, and fixes #3280, #7913 and #2528 (properly). Before this change, the output of `T2528` was (4x wrong): ``` [A,B] [1,2] False False ``` Reviewed By: dfeuer, ekmett, austin, hvr Differential Revision: https://phabricator.haskell.org/D238 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2528#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7913: Argument order not preserved by nubBy
by GHC 08 Nov '14

08 Nov '14

#7913: Argument order not preserved by nubBy -------------------------------------+------------------------------------- Reporter: paullik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: nubBy Operating System: Linux | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"a2e7bbfe7656cf7dbf1af4da5c077ac0b5d41127/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a2e7bbfe7656cf7dbf1af4da5c077ac0b5d41127" Preserve argument order to (==)/eq in nub and nubBy This makes nub and nubBy behave as specified in the Haskell 98 Report. This reverts 0ad9def53842e86fb292eccb810190711c42d7c5, and fixes #3280, #7913 and #2528 (properly). Before this change, the output of `T2528` was (4x wrong): ``` [A,B] [1,2] False False ``` Reviewed By: dfeuer, ekmett, austin, hvr Differential Revision: https://phabricator.haskell.org/D238 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7913#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3280: The order of arguments to the function passed to nubBy got swapped somehow
by GHC 08 Nov '14

08 Nov '14

#3280: The order of arguments to the function passed to nubBy got swapped somehow -------------------------------------+--------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | -------------------------------------+--------------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"a2e7bbfe7656cf7dbf1af4da5c077ac0b5d41127/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a2e7bbfe7656cf7dbf1af4da5c077ac0b5d41127" Preserve argument order to (==)/eq in nub and nubBy This makes nub and nubBy behave as specified in the Haskell 98 Report. This reverts 0ad9def53842e86fb292eccb810190711c42d7c5, and fixes #3280, #7913 and #2528 (properly). Before this change, the output of `T2528` was (4x wrong): ``` [A,B] [1,2] False False ``` Reviewed By: dfeuer, ekmett, austin, hvr Differential Revision: https://phabricator.haskell.org/D238 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3280#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0