June 2014 - ghc-tickets

[GHC] #9193: GHC panic usinig HList and Lens
by GHC 11 Jun '14

11 Jun '14

#9193: GHC panic usinig HList and Lens -------------------------------------------+------------------------------- Reporter: maxigit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: x86 | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- This bug might have been fixed in GHC 7.8.2 but I haven't been able to test it. Some packages required to reproduce the bug are broken under 7.8.*. GHC 'panic' whilst trying to compile the following. Strangely, removing doing the last line of code 'manually' in ghci works. {{{ {-# LANGUAGE TypeFamilies, DataKinds, PolyKinds, TypeOperators #-} {-# LANGUAGE NoMonomorphismRestriction #-} module Database.Harehouse.SQLFragment where import Data.HList import Control.Lens hiding(from) x = hLens' (Label :: Label "x") }}} Note. I'm using HList-0.3.4.1 and lens-4.1.2.1. I think it wasn't working with lens 4.2 either, but since I tried to install ghc 7.8.2 I haven't be able to reinstall lens 4.2. (cabal hell). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9193> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9187: Reduce number of missing wiki links by setting ignore_missing_pages in TracIni
by GHC 11 Jun '14

11 Jun '14

#9187: Reduce number of missing wiki links by setting ignore_missing_pages in TracIni -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The GHC wiki currently has lots of missing links, which makes for harder reading. A partial solution, from http://trac.edgewall.org/wiki/CamelCase: "There's an option (ignore_missing_pages in the [wiki] section of TracIni) to simply ignore links to missing pages when the link is written using the CamelCase style, instead of that word being replaced by a gray link followed by a question mark." Could this option be set for the GHC wiki? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9187> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9164: Hunt down uses of `castPtr`
by GHC 11 Jun '14

11 Jun '14

#9164: Hunt down uses of `castPtr` ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This bug is a fork from #9163: nomeata: Slightly off topic, but maybe `GHC.IO.Handle.Text` can be written so that `castPtr` is not needed. It seems it always works with `Ptr Word8`, but exposes an API that uses `Ptr a` as a generic pointer. The type `a` is never needed inside `GHC.IO.Handle.Text`... I tried it, and `hPutBuf` & Co are called with `Ptr Word8` (sometimes called LitString) in all cases but `BufWrite.bPutCStringLen`, where we have a `Ptr CChar`, where `CChar` is a newtype. So by using coerce there (and `unsafeCoerce` during bootstrapping), we get the best of boths worlds: The more restrictive role and the free behaviour. SPJ: Well regardless of the decision about the role of `Ptr`, what you describe sounds like an improvement anyway, getting rid of (always suspicious) `castPtr` calls. If you grep in the base library you'll find quite a few others. Can you eliminate them in the same way? I think this would be a nice improvement, if you cared to push it through. simonmar: So I've been assuming that `castPtr` was free all this time, and it turns out it isn't! Please make it free. We can't change the type of `hPutBuf` and friends without potentially breaking code. There's no better choice than `Ptr a` here, because we don't know the type of the underlying data. Making it `Ptr Word8` would just force the caller to use `castPtr` sometimes without any benefit. e.g. `Ptr CChar` is also a sensible choice, but it could in reality be anything. It does look like the two `castPtrs` in `bufWrite` are unnecessary, though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9164> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4442: Add unaligned version of indexWordArray#
by GHC 10 Jun '14

10 Jun '14

#4442: Add unaligned version of indexWordArray# --------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: libraries (other) | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by tibbe): * cc: duncan (added) * difficulty: => Unknown -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4442#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3372: Allow for multiple linker instances
by GHC 10 Jun '14

10 Jun '14

#3372: Allow for multiple linker instances -------------------------------------+------------------------------------ Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thomie): Corresponding wiki page: [wiki:MultipleLinkerInstances] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3372#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 10 Jun '14

10 Jun '14

#7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by ross): Replying to [comment:22 jstolarek]: > > They are subsets of xs: xs1 is the variables used by c, while xs2 is the > > variables used by ss but not bound in p. So the command 'c' gets local > > environment xs1 and stack (). The translations of statements are arrows that > > take an environment (here xs2) as input. > > That starts to make sense :-) As I understand `x1` and `x2` need not be > disjoint - is that correct? That's right. If a variable is used by both `c` and `ss`, it will be in both sets. > I am yet to understand the rules for encoding the input parameters to the arrows. > Is there a general rule that says when and in what order things are put on the stack? > Is it the case that elements on the stack are never accessed and need to be popped > if they are to be used? Things are added to the stack by `HsCmdApp` and removed with `HsCmdLam`, but stacks can also be modified by `HsCmdArrForm` - there are some examples in the "Primitive constructs" section in teh arrow notation part of the GHC User's Guide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files
by GHC 10 Jun '14

10 Jun '14

#1407: Add the ability to :set -l{foo} in .ghci files -------------------------------+------------------------------------------- Reporter: guest | Owner: archblob Type: feature | Status: patch request | Milestone: ⊥ Priority: normal | Version: 6.6.1 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by archblob): * owner: => archblob -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1407#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files
by GHC 10 Jun '14

10 Jun '14

#1407: Add the ability to :set -l{foo} in .ghci files -------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature | Status: patch request | Milestone: ⊥ Priority: normal | Version: 6.6.1 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by archblob): * cc: hvr (added) * status: new => patch Comment: There may be some nuances in the whole linking stuff that I don't understand, so please review. As far as I can tell the patch works as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1407#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 10 Jun '14

10 Jun '14

#7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by jstolarek): > They are subsets of xs: xs1 is the variables used by c, while xs2 is the > variables used by ss but not bound in p. So the command 'c' gets local > environment xs1 and stack (). The translations of statements are arrows that > take an environment (here xs2) as input. That starts to make sense :-) As I understand `x1` and `x2` need not be disjoint - is that correct? I am yet to understand the rules for encoding the input parameters to the arrows. Is there a general rule that says when and in what order things are put on the stack? Is it the case that elements on the stack are never accessed and need to be popped if they are to be used? I know all of this could be deduced from the source code, but sadly this is not straightforward (at least for me). > I don't understand that question - I don't see a bind expression in the generated code. What I meant is that desugaring of arrow bind is completely different from monadic bind (which is desugared to `>>=`+lambda) so perhaps it deserves its own internal representation. But in fact this is what my prototype implements ie. it distingushes arrow and monadic bind. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 10 Jun '14

10 Jun '14

#7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 7623, 8664 --------------------------------------------+------------------------------ Comment (by nomeata): Can we get this into 7.8.3 or 7.8.4? Debian will have to add this patch anyways, and I’m always keen on reducing delta. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0