February 2013 - ghc-tickets

Re: [GHC] #7379: rangeTest test fails on Windows
by GHC 10 Feb '13

10 Feb '13

#7379: rangeTest test fails on Windows ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by rassilon): Yeah, CWchar for CSigAtomic is a typo. wchar_t is always 16 bits on Windows OSs. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7379#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7353: Make system IO interruptible on Windows
by GHC 10 Feb '13

10 Feb '13

#7353: Make system IO interruptible on Windows ---------------------------------+------------------------------------------ Reporter: joeyadams | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Keywords: | Os: Windows Architecture: Unknown/Multiple | Failure: Incorrect result at runtime Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by ihameed): * cc: idhameed@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7353#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7595: Static flags code needs cleanup
by GHC 10 Feb '13

10 Feb '13

#7595: Static flags code needs cleanup -----------------------------+---------------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Component: Driver Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- While reading through the source code I noticed that code responsible for handling static flags could use some refactoring: * there are two modules that handle static flags: [[GhcFile(compiler/main/StaticFlags.hs)]] and [[GhcFile(compiler/main/StaticFlagParser.hs)]]. This is about 300 lines of code total and can be easily placed within a single file, especially that division of functions between these two files is sometimes confusing. * [[GhcFile(compiler/main/StaticFlags.hs)]] contains code responsible for handling dynamic flags. I will merge code from [[GhcFile(compiler/main/StaticFlagParser.hs)]] into into [[GhcFile(compiler/main/StaticFlags.hs)]], create a [[GhcFile(compiler/main/StaticFlags.hs-boot)]] to break module dependency cycles and move the code for handling dynamic flags to [[GhcFile(compiler/main/DynFlags.hs)]] -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7595> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #5793: make nofib awesome
by GHC 09 Feb '13

09 Feb '13

#5793: make nofib awesome --------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: _|_ Component: NoFib benchmark suite | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: 5794 Related: | --------------------------------------+------------------------------------- Comment(by simonmar): Replying to [comment:22 morabbin]: > Not sure if this is the place to report this, but without > {{{ > cabal install html > }}} > `nofib-analyse` won't compile, as it uses `Text.Html`. Where is the correct place to put this dependency? Moving `nofib-analyse` out into a Cabal package might be a good idea, and would resolve this. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5793#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5793: make nofib awesome
by GHC 09 Feb '13

09 Feb '13

#5793: make nofib awesome --------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: _|_ Component: NoFib benchmark suite | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: 5794 Related: | --------------------------------------+------------------------------------- Description changed by dterei: Old description: > Nofib is the standard tool GHC developers use to benchmark changes to the > compiler. Its overall design is OK but it's had no love and care for many > years and has bittrotted such that it isn't useful in a lot of > situations. > > This task is about making nofib useful again. > > The breakdown for this is something like: > > 1. Think and maybe fix nofib framework design. It has 'ways' which I > think correspond to compilation method but more in the sense of 'dynamic' > vs 'static', seems it may not suite being able to use ways for 'fasm' vs > 'fllvm'. There is also the concept of 'modes' which corresponds to > different benchmark input. So 'normal' and 'slow' for getting different > run-times. At moment no easy way to select which benchmark groups to run, > so may want to change that. I guess we should just decide, what knobs do > we want to be able to easily tweak, and see how well the current design > allows that. > > 2. Fixup the runtimes for benchmarks to be significant. This might be > best done by changing the way we run benchmarks and collect results to > make sure they are meaningful. > > E.g., Lots of great discussion and links to papers on this thread > > http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html > > 3. Above task is to fix normal but we may want to fixup slow as well and > perhaps add a 'fast' mode where benchmarks run in around 1 second. > > 4. Maybe add more benchmarks to the suite (text, bytestring, performance > regressions from ghc testsuite, vector....) New description: Nofib is the standard tool GHC developers use to benchmark changes to the compiler. Its overall design is OK but it's had no love and care for many years and has bittrotted such that it isn't useful in a lot of situations. This task is about making nofib useful again. The breakdown for this is something like: 1. Think and maybe fix nofib framework design. It has 'ways' which I think correspond to compilation method but more in the sense of 'dynamic' vs 'static', seems it may not suite being able to use ways for 'fasm' vs 'fllvm'. There is also the concept of 'modes' which corresponds to different benchmark input. So 'normal' and 'slow' for getting different run-times. At moment no easy way to select which benchmark groups to run, so may want to change that. I guess we should just decide, what knobs do we want to be able to easily tweak, and see how well the current design allows that. '''Note''' there is a shake build system attached that does a lot of this (done by Neil Mitchell!). An explanation of it can be found here: http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using- shake.html The design discussion of it is mostly lost as it was done on private email sorry. 2. Fixup the runtimes for benchmarks to be significant. This might be best done by changing the way we run benchmarks and collect results to make sure they are meaningful. E.g., Lots of great discussion and links to papers on this thread http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html 3. Above task is to fix normal but we may want to fixup slow as well and perhaps add a 'fast' mode where benchmarks run in around 1 second. 4. Maybe add more benchmarks to the suite (text, bytestring, performance regressions from ghc testsuite, vector....) -- -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5793#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5793: make nofib awesome
by GHC 09 Feb '13

09 Feb '13

#5793: make nofib awesome --------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: _|_ Component: NoFib benchmark suite | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: 5794 Related: | --------------------------------------+------------------------------------- Comment(by dterei): I put a note in http://hackage.haskell.org/trac/ghc/wiki/Building/RunningNoFib and also in the README file about the dependency. I don't think we should otherwise include the actual dependency if that was your implication. Thanks morabbin! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5793#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5793: make nofib awesome
by GHC 09 Feb '13

09 Feb '13

#5793: make nofib awesome --------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: _|_ Component: NoFib benchmark suite | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: 5794 Related: | --------------------------------------+------------------------------------- Comment(by morabbin): Not sure if this is the place to report this, but without {{{ cabal install html }}} `nofib-analyse` won't compile, as it uses `Text.Html`. Where is the correct place to put this dependency? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5793#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7675: Program lives on with dead main thread
by GHC 08 Feb '13

08 Feb '13

#7675: Program lives on with dead main thread -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86 Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control- Concurrent.html#g:13 says: In a standalone GHC program, only the main thread is required to terminate in order for the process to terminate. Thus all other forked threads will simply terminate at the same time as the main thread (the terminology for this kind of behaviour is "daemonic threads"). This isn't always true in ghc, as the following program demonstrates: {{{ % cat try.hs import Control.Concurrent import Control.Concurrent.STM import Control.Monad import System.Exit main :: IO () main = do x <- newTVarIO 0 forkIO $ forever $ do --atomically $ writeTVar x 42 --yield return () putStrLn "about to exit" exitSuccess putStrLn "dead" }}} {{{ % ghc -fforce-recomp try.hs [1 of 1] Compiling Main ( try.hs, try.o ) Linking try ... % ./try about to exit ^C^C }}} Instead of actually exiting, the program consumes 100% CPU despite the main thread being gone. The behavior is slightly different with `-threaded`: {{{ % ghc -fforce-recomp -threaded try.hs [1 of 1] Compiling Main ( try.hs, try.o ) Linking try ... % ./try ^C^C }}} Here it doesn't even execute the main thread. {{{ % ./try +RTS -N2 try: Using large values for -N is not allowed by default. Link with -rtsopts to allow full control. }}} I don't understand what's up with this. 2 isn't what I'd call "large". {{{ % ghc -fforce-recomp -threaded -rtsopts=all try.hs [1 of 1] Compiling Main ( try.hs, try.o ) Linking try ... % ./try +RTS -N2 about to exit }}} This version works as expected. Anyway, I'm not sure whether this is a bug in the RTS or in the documentation, but they clearly don't agree. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7675> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4429: Ability to specify the namespace in mkName
by GHC 08 Feb '13

08 Feb '13

#4429: Ability to specify the namespace in mkName ---------------------------------+------------------------------------------ Reporter: reinerp | Owner: reinerp Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Template Haskell | Version: 6.12.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by morabbin): * cc: andy.adamsmoran@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4429#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator)
by GHC 08 Feb '13

08 Feb '13

#2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) ---------------------------------+------------------------------------------ Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.11 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by JohnWiegley): * cc: johnw@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2959#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0