July 2014 - ghc-tickets

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

19 Jul '14

#6086: Cross compilation fails using system linker for other architecture binaries -------------------------------------+------------------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Operating System: Linux Differential Revisions: | Type of failure: Building GHC Architecture: arm | failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by boo): * version: 7.5 => 7.8.3 * architecture: Unknown/Multiple => arm * milestone: 7.8.1 => 7.8.4 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6086#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 19 Jul '14

19 Jul '14

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 6.8.1 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by pumpkin): Dan Doel pointed out that as useful as this could be, it would allow this fairly odd use case: {{{ #!haskell data Nat = Z | S Nat data Fin n where Zero :: Fin (S n) Suc :: Fin n -> Fin (S n) newtype SomeFin where SomeFin :: Fin n -> SomeFin suc :: SomeFin -> SomeFin suc (SomeFin n) = SomeFin (Suc n) inf :: SomeFin inf = suc inf }}} Which leads to `inf` containing a `Fin` whose existential index can't actually be any valid (finite) type. `Fin` thus becomes a bit of a misnomer in this context, since it's not finite. Making `SomeFin` into data rather than newtype fixes the problem by making `inf` into a bottom. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9321: Support for waiting on multiple MVars
by GHC 19 Jul '14

19 Jul '14

#9321: Support for waiting on multiple MVars -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: mvar | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- A lot of code in servers uses MVars because they seem to have more desirable scalability characteristics than STM. Unfortunately, unlike STM which is composable (i.e. `readTChan chan1 <|> readTChan chan2`), `MVar`s often require extra inefficient intermediate steps to funnel many-to-one. A common thing for people to do when they need to funnel N `MVar`s into one is to create 1 `MVar` and N forks where each fork attempts to read from its associated `MVar` and then writes it into the one `MVar` where another fork is waiting to process the data. This is such a waste; it produces more forks and another `MVar` where contention can occur. In some ways it would be better if the internal representation of an `MVar` had a pointer to the "next `MVar`" so that we could use a function like `eitherMVar` to merge two (or more) `MVar`s together into one which can be waited on and yield values from any of the containing `MVar`s. (I believe) the runtime would need to provide appropriate support in the scheduler so that the list is traversed instead of only the single `MVar` checked. The overhead for code which does not use this feature would probably be only 1 branch, which is acceptable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9321> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #5645: Sharing across functions causing space leak
by GHC 19 Jul '14

19 Jul '14

#5645: Sharing across functions causing space leak -------------------------------------+------------------------------------- Reporter: tener | Owner: Type: bug | Alexander.Pakhomov Priority: normal | Status: new Component: Compiler | Milestone: 7.10.1 Resolution: | Version: 7.2.1 Differential Revisions: | Keywords: Architecture: | Operating System: Unknown/Multiple Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------+------------------------------------- Changes (by Alexander.Pakhomov): * owner: => Alexander.Pakhomov * difficulty: => Unknown Comment: I hope this could be done with GC modifications. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5645#comment:6> 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 18 Jul '14

18 Jul '14

#6086: Cross compilation fails using system linker for other architecture binaries -------------------------------------+------------------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build | Version: 7.5 System | Keywords: Resolution: | Operating System: Linux Differential Revisions: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by boo): * owner: simonmar => * status: closed => new * resolution: fixed => Comment: I'm just trying to crosscompile GHC-7.8.3 from Linux (x86) to Raspberry Pi following [wiki:Building/Preparation/RaspberryPi this instruction] and getting following error: {{{ "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install "" --with-ghc="/home/boo/projects/rpi/ghc-7.8.3/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/boo/projects/rpi/ghc-7.8.3/inplace/bin/ghc-pkg" --flag=include-ghc-prim --disable-library-for-ghci --enable-library- vanilla --disable-library-profiling --enable-shared --configure- option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --configure-option=--host=arm-unknown-linux-gnueabihf --with- gcc="/usr/bin/gcc" --with-ld="/home/boo/projects/rpi/tools/arm-bcm2708 /gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-ld" --configure-option=--with-cc="/usr/bin/gcc" --with- ar="/home/boo/projects/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux- gnueabihf-raspbian/bin/arm-linux-gnueabihf-ar" --with- ranlib="/home/boo/projects/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux- gnueabihf-raspbian/bin/arm-linux-gnueabihf-ranlib" --with- alex="/usr/local/bin/alex" --with-happy="/usr/local/bin/happy" Configuring ghc-prim-0.3.1.0... ghc-cabal: /tmp/3624.o: does not exist make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6086#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 17 Jul '14

17 Jul '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 Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #4259 | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:41 jstolarek]: > This is beyond my knowledge - I would require some guidance here. But if it's possible to implement injective type families without this change then I would postpone it until later and possibly consider it a separate task. Yes, it's possible, but there are some circumstances in which users could say that GHC gives an erroneous type error, in that GHC would manifestly have enough knowledge to make progress but doesn't. I agree that you should go ahead without this piece, though! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 17 Jul '14

17 Jul '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 Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #4259 | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:40 goldfire]: > I'm still not sold on the concrete syntax involving `result`, despite having introduced that idea myself. I like the `(**)` suggestion here a bit more: http://www.haskell.org/pipermail/ghc-devs/2014-July/005492.html So, to be precise, with this syntax the examples from the wiki page would look like this: {{{ type family F a b c | F -> a b c type family G a b c | G -> a b type family H a b c | H a -> b c, H b -> a c, H c -> a b type family J a b c | J a -> b c, J b -> a c }}} I did not propose to use the notation like `H b -> a c` because I thought it might mislead people to think that: a) `H` could be partially applied; b) some parameters of `H` could be skipped (ie. we can apply it to `b` without first applying to `a`). Luckily, this is not a blocking issue for the rest of implementation. It should only affect 3 files in the parser, so it can be changed later. > Separately, a change to Core will be necessary to really make this work in all cases. > > (...) > > All that said, this use case is obscure, and the primary push for injective type families does not seem to require a change to Core. It is worth implementing without this piece. But, the idea came up in conversation, and I thought I should record it. This is beyond my knowledge - I would require some guidance here. But if it's possible to implement injective type families without this change then I would postpone it until later and possibly consider it a separate task. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 16 Jul '14

16 Jul '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 Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #4259 | -------------------------------------+------------------------------------- Comment (by goldfire): I'm still not sold on the concrete syntax involving `result`, despite having introduced that idea myself. I like the `(**)` suggestion here a bit more: http://www.haskell.org/pipermail/ghc-devs/2014-July/005492.html Separately, a change to Core will be necessary to really make this work in all cases. {{{ data X a where MkX :: (F b c ~ a) => b -> c -> X a }}} Say `F` is injective (in both arguments). After pattern-matching on `MkX ... :: X (F Int Bool)`, we will probably want to discover that `b` is `Int` and `c` is `Bool`. To do so, we will need to decompose the `(F b c ~ a)` coercion, using the '''left''' and '''right''' (or perhaps '''nth''') coercion forms. These currently don't work over type families, and for good reason. However, if a type family is injective, then these ''could'' be made to work over type families. With the update to Core, we would probably want to make sure we don't lose type safety, though! All that said, this use case is obscure, and the primary push for injective type families does not seem to require a change to Core. It is worth implementing without this piece. But, the idea came up in conversation, and I thought I should record it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7379: rangeTest test fails on Windows
by GHC 16 Jul '14

16 Jul '14

#7379: rangeTest test fails on Windows -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.1 libraries/random | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: rrnewton (added) * status: new => patch Comment: https://github.com/haskell/random/pull/5 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7379#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8013: Strange closure type error building hs-kqueue on FreeBSD
by GHC 16 Jul '14

16 Jul '14

#8013: Strange closure type error building hs-kqueue on FreeBSD -------------------------------------+------------------------------------- Reporter: ahktenzero | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 (LLVM) | Keywords: Resolution: worksforme | Operating System: FreeBSD Differential Revisions: | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: infoneeded => closed * resolution: => worksforme -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8013#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0