- ghc-tickets - Haskell.org

Re: [GHC] #7830: Error: operand out of range
by GHC 26 Feb '14

26 Feb '14

#7830: Error: operand out of range ------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------------+--------------------------- Changes (by trommler): * cc: ptrommler@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8807: Variable constraints not handled properly in TH
by GHC 26 Feb '14

26 Feb '14

#8807: Variable constraints not handled properly in TH ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template Haskell | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I compile {{{ {-# LANGUAGE TemplateHaskell, ConstraintKinds #-} module Scratch where import Data.Proxy foo :: $( [t| a b => Proxy a -> b -> b |] ) foo = undefined }}} I get {{{ Illegal type constructor or class name: ‛a’ When splicing a TH type: forall a_0 b_1 . a_0 b_1 => Data.Proxy.Proxy a_0 -> b_1 -> b_1 In the splice: $([t| a b => Proxy a -> b -> b |]) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8807> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5013: sporadic failures during compilation under solaris
by GHC 26 Feb '14

26 Feb '14

#5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Changes (by kgardas): * status: new => patch * version: 7.6.1 => 7.9 * milestone: 7.6.2 => Comment: I've tested the patch on Solaris/sparc while building GHC from NFS Solaris drive and it runs fine even with gmake -j32 which always fails without the patch. I've attached git patch for easy merging to HEAD. Thanks for review and Christian for providing it! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5013#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8813: further support deriving instances Typeable1, Typeable2, etc
by GHC 26 Feb '14

26 Feb '14

#8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------+---------------------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- ghc-7.8.20140130 complains with {{{ Not in scope: type constructor or class ‛Typeable2’ Perhaps you meant ‛Typeable’ (imported from Data.Typeable) }}} changing Typeable2 to Typeable fixes it but is incompatible with ghc-7.6: {{{ Expecting two more arguments to `Gr' In the stand-alone deriving instance for `Typeable Gr' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8813> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

Re: [GHC] #2507: quotation characters in error messages
by GHC 25 Feb '14

25 Feb '14

#2507: quotation characters in error messages -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.8.1 Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2811,#3398 -------------------------------------+------------------------------------ Changes (by hvr): * milestone: 7.6.2 => 7.8.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2507#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2507: quotation characters in error messages
by GHC 25 Feb '14

25 Feb '14

#2507: quotation characters in error messages -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2811,#3398 -------------------------------------+------------------------------------ Changes (by hvr): * status: merge => closed * resolution: => fixed Comment: Replying to [comment:33 hvr]: > I'm setting this ticket to `merge` to have this considered for merging into GHC 7.8 (meaning, I'll leave the decision up to Austin :-) after conferring with Austin, I've merged this into ghc-7.8 as [ebb9bd36b80040dc/ghc] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2507#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8823: showFloat for higher precision types produces strange results for some values
by GHC 25 Feb '14

25 Feb '14

#8823: showFloat for higher precision types produces strange results for some values --------------------------+------------------------------------------------ Reporter: axman6 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.8.1-rc1 Prelude | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I've written a library which is a quda-double type a la the QD C/C++ package, and showFloat does not behave correctly for numbers with such high precision. My type has ~212 bits of precision, and when using showFloat from Numeric, I get strange results for integer values: {{{ show (1 :: QDouble) = "0.00000000000000000000000000000000000000000000001e47" show (1.1 :: QDouble) = "1.1" show (1000 :: QDouble) = "0.00000000000000000000000000000000000000000000001e50" -- These seems to suggest it happens for any number with only a -- few high bits set to 1 in the result of decodeFloat show (1.125 :: QDouble) = "0.00000000000000000000000000000000000000000000001125e47" show (1.625 :: QDouble) = "0.00000000000000000000000000000000000000000000001625e47" }}} The problem seems to be related to the result of floatDigits, which starts causing problem when it's larger than 56 (floatDigits x, show x): {{{ (56,"1.0") (57,"01.0") (60,"001.0") (212,"0.00000000000000000000000000000000000000000000001e47") }}} My fix has been to use a modified version of showFloat from Numeric by changing the floatToDigits function to include a fix for times when large numbers of zeros are produced: {{{ fixup2 (xs,k) = let (zs,ys) = span (==0) xs in (ys,k-length zs) in fixup2 (map fromIntegral (reverse rds), k) }}} This fixes the symptom but not the issue itself (though it seems like a reasonable thing to have any result returned by floatToDigits. I have attached as minimal test case as I could come up with. Using floatToDigits from Numeric causes the strange behaviour, while floatToDigits' included in the test case does not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8823> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8818: Add withMVarMasked
by GHC 25 Feb '14

25 Feb '14

#8818: Add withMVarMasked ------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We already have `modifyMVarMasked` and `modifyMVarMasked_`, and so I propose to add {{{#!haskell {-| Like 'withMVar', but the @IO@ action in the second argument is executed with asynchronous exceptions masked. /Since: 4.7.0.0/ -} {-# INLINE withMVarMasked_ #-} withMVarMasked :: MVar a -> (a -> IO b) -> IO b withMVarMasked m io = mask_ $ do a <- takeMVar m b <- io a `onException` putMVar m a putMVar m a return b }}} any arguments against this addition? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8818> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #2507: quotation characters in error messages
by GHC 25 Feb '14

25 Feb '14

#2507: quotation characters in error messages -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: merge Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2811,#3398 -------------------------------------+------------------------------------ Comment (by hvr): FYI, just found this related article [http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html ASCII and Unicode quotation marks], which is summarised as follows: > Please do not use the ASCII grave accent (0x60) as a left quotation mark together with the ASCII apostrophe (0x27) as the corresponding right quotation mark (as in `quote'). Your text will otherwise appear rather strange with most modern fonts (e.g., on Windows and Mac systems). Only old X Window System fonts and some old video terminals show ASCII 0x60/0x27 as left and right quotation marks, while most modern systems follow the ISO and Unicode standards instead. > > If you can use only ASCII’s typewriter characters, then use the apostrophe character (0x27) as both the left and right quotation mark (as in 'quote'). If you can use Unicode characters, nice directional quotation marks are available in the form of characters U+2018, U+2019, U+201C, and U+201D (as in ‘quote’ or “quote”). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2507#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2507: quotation characters in error messages
by GHC 25 Feb '14

25 Feb '14

#2507: quotation characters in error messages -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: merge Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2811,#3398 -------------------------------------+------------------------------------ Changes (by hvr): * status: patch => merge Comment: I'm setting this ticket to `merge` to have this considered for merging into GHC 7.8 (meaning, I'll leave the decision up to Austin :-) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2507#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0