- ghc-tickets - Haskell.org

Re: [GHC] #8010: Add forkOSUnmasked (patch)
by GHC 16 Sep '14

16 Sep '14

#8010: Add forkOSUnmasked (patch) -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Proposal has passed with a little support and no resistance, so I guess we're good to go? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8010#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9595: GHCi tab autocomplete include invisible modules
by GHC 15 Sep '14

15 Sep '14

#9595: GHCi tab autocomplete include invisible modules -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Reported to me by hvr. It was broken in the refactoring of the package code. We need a test for this. Long term, we need to do something more reasonable when there are duplicate modules, since autocomplete will suggest the name, but we can't actually handle it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9595> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #9554: Pathological type family turns type error into runtime loop
by GHC 15 Sep '14

15 Sep '14

#9554: Pathological type family turns type error into runtime loop -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9554#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 15 Sep '14

15 Sep '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by danilo2): @jstolarek: Yes, I've got an example here - by the way, I would be very thankful if you look at it, because I'm scratching my head against it for over two days now and cannot solve it in any way. But this problem is very specific one - you can read detailed description and solutions attemps here: http://stackoverflow.com/questions/25854072/injective-type-families- in-haskell -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:65> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3658: Dynamically link GHCi (and use system linker) on platforms that support it
by GHC 15 Sep '14

15 Sep '14

#3658: Dynamically link GHCi (and use system linker) on platforms that support it -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: task | Status: closed Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 6.10.4 Resolution: fixed | Keywords: dynamic link Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 1883, | 3242, 3372, 3654, 4244, 5062, | 5197, 6107, 7072, 7103, 7316, | 7389, 7475, 7687 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * blockedby: 5987 => Comment: I'm going to close this out of the rationale that #5987 is really a regression: dynamically linked GHC should work on Windows, but currently doesn't. Nonetheless, we do link on platforms where we support it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3658#comment:55> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 15 Sep '14

15 Sep '14

#7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: jstolarek AlessandroVermeulen | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #1537, #3613 Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D72 | -------------------------------------+------------------------------------- Comment (by simonpj): See also [http://blog.spacekitteh.moe/posts/new-monoidal-cats.html Sophie Taylor's proposal] about monoidal category classes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 15 Sep '14

15 Sep '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): > what's wrong with exponential time here? Compilation times. If a type family takes a single argument then obviously there is only one possible injectivity condition ("result -> a"). For two arguments there are 5 possible injectivity conditions. For 3 this number jumps to 19. 4 arguments => 65 combinations. 5 arguments => 211 combinations. 6 arguments => 665 combinations. Let's assume (for illustrative purposes) that verifying (ie. attempting to infer) a single injectivity condition for a type family takes 0.01s. Under such assumptions inferring all possible injectivity conditions for a type family with 6 arguments will take ~6.5s. We can't do that. > Is there any patch which would allow me to use injective type families in current GHC? No. But if all goes well all this discussion here will culminate with such a patch :-) In the meantime, if you have any motivating use cases that require injectivity to work please share them if you can. This would be most helpful. I've spent last several days thinking intensely about the design and made some progress. Hopefully, I'll incorporate my notes into the wiki page by the end of the week. Will get back with some ideas and proposals once this happens. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:64> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4426: Simplify the rules for implicit quantification
by GHC 14 Sep '14

14 Sep '14

#4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: low | Version: 6.12.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7880 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D211 | -------------------------------------+------------------------------------- Changes (by monoidal): * status: infoneeded => patch * differential: => Phab:D211 Comment: The patch (ghc+haddock) is ready for review in Phabricator, and the change to haskeline was merged. There are only minor changes since the previous patch - I've clarified the documentation and updated TH testcases that were created in the meantime. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4426#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries
by GHC 14 Sep '14

14 Sep '14

#6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9421 | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by cetu86): Inside your cross toolchain there is a directory that is literally called "sysroot". Inside it you'll find your standard unix root. Looks like this {{{ . └── arm-unknown-linux-gnueabi ├── arm-unknown-linux-gnueabi │ └── sysroot │ ├── bin │ ├── etc │ ├── include │ ├── lib │ ├── sbin │ ├── share │ ├── usr │ │ ├── bin │ │ ├── include --> ncurses.h, curses.h go here │ │ ├── lib --> libncurses.a goes here │ └── var }}} If you use ".../sysroot/usr" as prefix everything should go fine. Except ncurses puts its header files in a subdirectory "include/ncurses" but ghc includes the header file as {{{ #include <ncurses.h> }}} not as {{{ #include <ncurses/ncurses.h> }}} What it did was move all files in the ncurses directory one up and create a symlink for compatibility. (in case I'd later install something that expects ncurses in its original place) Like this: {{{ cd sysroot/usr/inlude/ncurses mv * .. cd .. rmdir ncurses ln -s . ncurses }}} Now I have {{{ daniel@inferno:~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux- gnueabi/sysroot/usr/include/ > ls -l ncurs* curs* -rw-r--r-- 1 daniel users 6590 9. Sep 12:38 cursesapp.h -rw-r--r-- 1 daniel users 27646 9. Sep 12:38 cursesf.h -rw-r--r-- 1 daniel users 76252 9. Sep 12:38 curses.h -rw-r--r-- 1 daniel users 19518 9. Sep 12:38 cursesm.h -rw-r--r-- 1 daniel users 8489 9. Sep 12:38 cursesp.h -rw-r--r-- 1 daniel users 49280 9. Sep 12:38 cursesw.h -rw-r--r-- 1 daniel users 7312 9. Sep 12:38 cursslk.h lrwxrwxrwx 1 daniel users 1 9. Sep 14:19 ncurses -> . -rw-r--r-- 1 daniel users 3925 9. Sep 12:38 ncurses_dll.h lrwxrwxrwx 1 daniel users 8 9. Sep 12:38 ncurses.h -> curses.h }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6086#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9585: Note about semantics of (!!) is not specific enough, if it's correct
by GHC 12 Sep '14

12 Sep '14

#9585: Note about semantics of (!!) is not specific enough, if it's correct -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The definition of `(!!)` in `GHC.List`, copied below, has a vague note about semantics for the Prelude and HBC versions being different. I can't see the difference myself. If there really is a difference, the details should be in the comment. {{{#!hs -- | List index (subscript) operator, starting from 0. -- It is an instance of the more general 'Data.List.genericIndex', -- which takes an index of any integral type. (!!) :: [a] -> Int -> a #ifdef USE_REPORT_PRELUDE xs !! n | n < 0 = error "Prelude.!!: negative index" [] !! _ = error "Prelude.!!: index too large" (x:_) !! 0 = x (_:xs) !! n = xs !! (n-1) #else -- HBC version (stolen), then unboxified -- The semantics is not quite the same for error conditions -- in the more efficient version. -- xs !! (I# n0) | isTrue# (n0 <# 0#) = error "Prelude.(!!): negative index\n" | otherwise = sub xs n0 where sub :: [a] -> Int# -> a sub [] _ = error "Prelude.(!!): index too large\n" sub (y:ys) n = if isTrue# (n ==# 0#) then y else sub ys (n -# 1#) #endif }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9585> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2