May 2013 - ghc-tickets

Re: [GHC] #5925: Add inline version of newArray#
by GHC 08 May '13

08 May '13

#5925: Add inline version of newArray# ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: 4258 | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): If the array size is fixed at compile time, it should be easy... the heap check can be aggregated with all the others at the start of the basic block. If the array size is not known at compile time, but somehow known to be small, then with the new codegen it should be possible to just emit an inline heap check. EXCEPT that doing so could mess up downstream fixed- size checks. Eg {{{ let x = f v in let y = newArray# n# in let z = f w in ... }}} Absent the `newArray#` we'd have a single heap check that made sure there was enough space for both `x` and `z`. But we can't do that if the `newArray#` in the middle allocates an unknown amount of space. I suppose we could emit three heap checks... that would work I think. A related ticket is #2387 and #2289, where we'd like to put a heap check at the beginning of a primop case alternative, something that should now work just fine. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5925#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4370: Bring back monad comprehensions
by GHC 08 May '13

08 May '13

#4370: Bring back monad comprehensions -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by carter): does some of the constraint kinds / poly kinds machinery allow the remainder of this ticket to be addressed? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4370#comment:67> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7895: Warning for literal overflow
by GHC 08 May '13

08 May '13

#7895: Warning for literal overflow -----------------------------+---------------------------------------------- Reporter: acube | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Using ghc 7.6.3, the following compiles without warnings on -Wall: {{{ import Data.Word test :: Word8 test = 300 main = print test }}} I expected this to issue a warning like: "Warning: literal overflow on line 4". I know GCC for example does this and it would be nice if GHC did this too. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7895> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5925: Add inline version of newArray#
by GHC 08 May '13

08 May '13

#5925: Add inline version of newArray# ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: 4258 | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by tibbe): I don't think anyone is working on this. Simon, last time I tried I got stuck not understanding how to properly emit an inline heap check using the helper module for heap stuff. Is it now easier with the new codegen? It's a tiny bit frustrating knows how the code I want to emit looks like (it's an if and a jump more or less!) but not being able to generate that code. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5925#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5925: Add inline version of newArray#
by GHC 08 May '13

08 May '13

#5925: Add inline version of newArray# ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: 4258 | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by carter): whats the status on this? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5925#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7839: After forkIO'ing on Intel Mac, putStrLn (presumably) reports "hPutChar: failed (Operation not supported)"
by GHC 07 May '13

07 May '13

#7839: After forkIO'ing on Intel Mac, putStrLn (presumably) reports "hPutChar: failed (Operation not supported)" ----------------------------------------+----------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: MacOS X | Architecture: x86 Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- Investigating #7715 on the tn23 builder, which is {{{ $ uname -a Darwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 $ }}} I ran into: {{{ $ cat T7715O.hs import Control.Monad import Control.Concurrent import System.IO import System.Environment main' c d2 = do replicateM_ c $ forkIO $ do putStrLn "Hello, world!" threadDelay d2 mainArgsInterpret [cS,d2S] = main' (read cS) (read d2S) main :: IO () main = do hSetBuffering stdout NoBuffering hSetBuffering stderr NoBuffering args <- getArgs mainArgsInterpret args $ /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/inplace/bin /ghc-stage2 --make T7715O.hs -threaded -debug -rtsopts [1 of 1] Compiling Main ( T7715O.hs, T7715O.o ) Linking T7715O ... $ ./T7715O 25 10000000 Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! HeT7715O: <stdout>: hPutChar: failed (Operation not supported) T7715O: <stdout>: hPutChar: failed (Operation not supported) $ }}} This doesn't happen on {{{ $ uname -a Linux tn24 3.2.0-39-generic #62-Ubuntu SMP Wed Feb 27 22:05:17 UTC 2013 i686 i686 i386 GNU/Linux $ }}} Best regards Thorkil -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7839> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7268: Explicit type signatures for top level record pattern matches polymorphism fail
by GHC 07 May '13

07 May '13

#7268: Explicit type signatures for top level record pattern matches polymorphism fail ----------------------------------------+----------------------------------- Reporter: TristanAllwood | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC rejects valid program Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------------+----------------------------------- Changes (by MartijnVanSteenbergen): * cc: martijn@… (added) Comment: Some more info and examples can be found in #7891. Notably, for the program above, an extra indirection makes it ok again to give a type signature: {{{ id'' :: a -> a id'' = id' }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7268#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7893: GHCi :k shouldn't require type family arguments
by GHC 07 May '13

07 May '13

#7893: GHCi :k shouldn't require type family arguments ----------------------------------+----------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Hi, {{{ type family F t :: * }}} If I load this program in GHCi and ask for F's kind using `:k F`, I get the error: {{{ Type synonym `F' should have 1 argument, but has been given none }}} I expect GHCi to be able to tell me the kind of F without satisfying its type parameters first. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7893> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7773: Waiting on non-kqueue supported files on OS X
by GHC 06 May '13

06 May '13

#7773: Waiting on non-kqueue supported files on OS X ----------------------------------------+----------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.7 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- Neither the old IO manager nor the new "parallel" IO manager properly handle waiting on files on Mac OS X when kqueue does not support the device type. PHO reported this on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/000798.html. Here is the gist of it: the IO manager uses kqueue to wait on files on OS X. kqueue does not support all files. For example, on older versions of OS X (10.5.8) it cannot wait on tty devices and on even on 10.8.2 it cannot wait on /dev/random. Both the old and parallel IO managers suffered from the problem, but the consequences were slightly different. With the old IO manager the situation was treated as the file being ready, which would just cause the waiting thread to run again. The parallel IO manager changed things slightly and now it just throws an exception and terminates the program. So the behavior when this happens in the parallel IO manager is not acceptable. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7773> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #7870: Compilation errors break the complexity encapsulation on DSLs, impairs success in industry
by GHC 05 May '13

05 May '13

#7870: Compilation errors break the complexity encapsulation on DSLs, impairs success in industry -----------------------------+---------------------------------------------- Reporter: agocorona | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.7 | Keywords: DSL, Error, Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- From the paper "Scripting the Type Inference Process" -Bastiaan Heeren Jurriaan Hage S. Doaitse Swierstra: ... Combinator languages are a means of deﬁning domain speciﬁc languages embedded within an existing programming language, using the abstraction facilities present in the latter. However, since the domain speciﬁc extensions are mapped to constructs present in the underlying language, all type errors are reported in terms of the host language, and not in terms of concepts from the combinator library. In addition, the developer of a combinator library may be aware of various mistakes which users of the library can make, something which he can explain in the documentation for the library, but which he cannot make part of the library itself. ...As a result, the beginning programmer is likely to be discouraged from pro-gramming in a functional language, and may see the rejection of programs as a nuisance instead of a blessing. The experienced user might not look at the messages at all. Definitively this is probably the biggest barrier for the acceptance of Haskell on Industry. We need to start with something not as sophisticated as the Helium paper "Scripting the Type Inference Process", but maybe a partial implementation of the techniques mentioned, so that the development can be enhanced in the future. Maybe some kind of library that permits postprocessing of GHC errors and/or the identification of points in the current type checker where some kind of rules can be defined by the programmer can be the first step. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7870> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4