- ghc-tickets - Haskell.org

Re: [GHC] #4385: Type-level natural numbers
by GHC 09 Oct '13

09 Oct '13

#4385: Type-level natural numbers --------------------------------------------+------------------------------ Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by ghorn): * cc: gregmainland@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4385#comment:65> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8418: [patch] comments outdated
by GHC 09 Oct '13

09 Oct '13

#8418: [patch] comments outdated -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- During working on GHC, I found these outdated comments and function names. The ForPlugins renaming is DynamicLoading.hs is motivated by the fact that chnage 57d6798 crippled the function in a way that now it can only be used while handling Plugins. Therefore the name should warn the programmer to this fact. The hptInstances comment has also been outdated, when someone needed to add the `ModuleName -> Bool` predicate to use this same function for handling ghc and ghci with shared code. The attached patch is trivial renames/comments. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8418> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8223: System.Posix.User fails to build on systems without get{gr, pw}nam_r
by GHC 09 Oct '13

09 Oct '13

#8223: System.Posix.User fails to build on systems without get{gr,pw}nam_r ----------------------------------+---------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.7 Keywords: | Operating System: Other Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- I'm trying to build GHC for Android (using https://github.com/neurocyte /ghc-android) and according to `include/HsUnixConfig.h` Android doesn't have any of the `_r` functions in the `get{gr,pw}*` family. In `System/Posix/User.hsc` the imports of `Control.Monad` and `System.IO.Error` are conditional on `defined(HAVE_GETGRNAM_R) || defined(HAVE_GETPWNAM_R)`, but the use site of those modules (`doubleAllocWhileERANGE`) was moved outside of any `#if`s by http://git.haskell.org/?p=packages/unix.git;a=commit;h=ef683c6ba703. I would suggest just removing the conditionals around the import of those two modules, since `doubleAllocWhileERANGE` is by now used by four other functions. Otherwise, need to bracket the definition of `doubleAllocWhileERANGE` with the same conditional as the one around those imports, and should update the conditionals to reflect all four cases in which `doubleAllocWhileERANGE` is used. (BTW, does Android count as "Operating System: Linux"? It is based on the Linux kernel, but with a rather peculiar user-space.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8408: Ambiguity in TH reify based on compilation method
by GHC 09 Oct '13

09 Oct '13

#8408: Ambiguity in TH reify based on compilation method ------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: low | 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: | ------------------------------------+------------------------------------- The attached tar.gz contains a simple example where compiling with --make results in a different semantics than compiling all the modules with -c and then linking them together. This is shown by build.sh, so just start by running that. The ambiguity comes from the fact that the compiler is not starting the compilation of modules with a clean slate when using --make. This can be seen in compiler/iface/LoadIface.lhs line 276. I'm not sure if/how we should do anything about this urgently. Just wanted to note down this ambiguity, so we know it's there and can care about fixing it if we want to. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8408> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7685: :script command does not resolve ~
by GHC 09 Oct '13

09 Oct '13

#7685: :script command does not resolve ~ -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner <mail@…>): In [changeset:"ddc79b229d58c1bed8ae19b955b491436e015e96/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ddc79b229d58c1bed8ae19b955b491436e015e96" GHCi: Expand ~ in :script command Fixes: #7685 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7685#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7685: :script command does not resolve ~
by GHC 09 Oct '13

09 Oct '13

#7685: :script command does not resolve ~ -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): Joachim, looks good to me. Please feel free to push it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7685#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8367: putStrLn and related printing functions don't output to MinTTY properly under Windows
by GHC 09 Oct '13

09 Oct '13

#8367: putStrLn and related printing functions don't output to MinTTY properly under Windows ------------------------------------+--------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- One place where this glitch can be seen in `cabal update` by it *delaying* the term output until the update is finished and the program terminates. I've noticed it in several of my personal larger projects too. I think what's going on is that nothing is printed to the terminal until the program terminates. It seems to be intermittent to some degree, and varying the size and contents of the program can trigger it. Because of it's indeterminacy I can't actually provide a small test case, however, I can provide a program which currently does produce the issue. https://github.com/kvanberendonck/burrito/blob/ccd8d1fb2bb09251571cf2626314… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8367> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #3553: parallel gc suffers badly if one thread is descheduled
by GHC 09 Oct '13

09 Oct '13

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Replying to [comment:13 simonmar]: > I'm very tempted to change the main thread to be non-bound. If so, would the earlier commits that helped mitigate this particular slowdown be undone? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3553#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4259: Relax restrictions on type family instance overlap
by GHC 09 Oct '13

09 Oct '13

#4259: Relax restrictions on type family instance overlap --------------------------------------------+------------------------------ Reporter: lilac | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8423 --------------------------------------------+------------------------------ Changes (by goldfire): * related: => #8423 Comment: See also #8423 to see an example of this issue in action in the context of closed type families. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4259#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7919: Heap corruption (segfault) from large 'let' expression
by GHC 08 Oct '13

08 Oct '13

#7919: Heap corruption (segfault) from large 'let' expression -----------------------------------+---------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by george.colpitts): * cc: george.colpitts@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7919#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0