November 2013 - ghc-tickets

Re: [GHC] #7477: reifyInstances can't deal with polykinded type families
by GHC 06 Nov '13

06 Nov '13

#7477: reifyInstances can't deal with polykinded type families -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: bug | Milestone: 7.8.1 Priority: | Version: 7.7 normal | Keywords: TemplateHaskell TypeFamilies Component: | PolyKinds Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"8944fd3fc5fa7d435f438c5680c8d177257d27e9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8944fd3fc5fa7d435f438c5680c8d177257d27e9" Zonk the type in reifyInstances (fixes Trac #7477) A simple oversight, but crucial! tcLHsType was returning F k Int where k is a unification variable that has been unified with * }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7477#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8504: Provide minor GC residency estimates
by GHC 06 Nov '13

06 Nov '13

#8504: Provide minor GC residency estimates -------------------------------------------+------------------------------- Reporter: ezyang | Owner: simonmar Type: feature request | Status: new Priority: lowest | Milestone: Component: Runtime System | Version: 7.7 Keywords: easy | 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: -------------------------------------------+------------------------------- Currently, the residency statistics (e.g. max residency and current residency) are only updated when a major garbage collection occurs. While this is the only way to ensure an accurate residency count, there are times when a residency estimate would be desirable, since only taking the sample on major GC can be somewhat low resolution. We already collect and report this information on verbose GC stats, so all that needs to be done is to expose it via GHC.Stats. Should be an easy patch, good for someone who wants to play around in the RTS. Here is a simple patch that switches residency to the inaccurate version: {{{ diff --git a/rts/Stats.c b/rts/Stats.c index c19f23c..c71d0fb 100644 --- a/rts/Stats.c +++ b/rts/Stats.c @@ -449,7 +449,6 @@ stat_endGC (Capability *cap, gc_thread *gct, CAPSET_HEAP_DEFAULT, mblocks_allocated * MBLOCK_SIZE_W * sizeof(W_)); - if (gen == RtsFlags.GcFlags.generations-1) { /* major GC? */ if (live > max_residency) { max_residency = live; } @@ -459,7 +458,6 @@ stat_endGC (Capability *cap, gc_thread *gct, traceEventHeapLive(cap, CAPSET_HEAP_DEFAULT, live * sizeof(W_)); - } if (slop > max_slop) max_slop = slop; } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8504> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7831: Bad fragmentation when allocating many large objects
by GHC 06 Nov '13

06 Nov '13

#7831: Bad fragmentation when allocating many large objects -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 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 simonmar): * cc: simonmar (added) Comment: josef: O'Caml is a bit different, the situation there is fragmentation in the heap itself because the old-generation collector doesn't move objects. We don't have that issue in GHC, at least for small objects, but there's a related issue in the layer beneath the GC (the block allocator) that Edward's program nicely illustrates here. I doubt this is ever an issue in practice. The fragmentation that arises this way is bounded: at worst the fragmentation will be equal to the amount of memory used for large objects. And in most cases (a) it will be less than this because the sizes of large objects are never exactly 0.5MB, and (b) the fragmented space will be used to store small objects, so it won't be wasted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7831#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8499: Template Haskell: newName not new enough
by GHC 06 Nov '13

06 Nov '13

#8499: Template Haskell: newName not new enough ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I compile this: {{{ {-# LANGUAGE TemplateHaskell, PolyKinds, DataKinds #-} {-# OPTIONS_GHC -Wall #-} import Language.Haskell.TH $( do TyConI (DataD _ _ [PlainTV tvb_a] _ _) <- reify ''Maybe my_a <- newName "a" return [TySynD (mkName "SMaybe") [KindedTV my_a (AppT (ConT ''Maybe) (VarT tvb_a))] (TupleT 0)] ) }}} I get this: {{{ /Users/rae/temp/Bug.hs:6:4: Warning: This binding for ‛a’ shadows the existing binding bound at /Users/rae/temp/Bug.hs:6:4 }}} The problem is that, in the library definition for `Maybe`, the name of its type variable is `a`. In my Template Haskell code, I read in `Maybe`'s definition (using `reify`) to extract the name of `Maybe`'s type variable. I then create a new name, also seeded with `"a"`. Then, I create a type synonym definition {{{ type SMaybe (a_newName :: Maybe a_Maybe) = () }}} where `a_newName` is the variable I `newName`d, and `a_Maybe` is the name I slurped from `Maybe`'s definition. These variables print with different uniques, but the warning comes up anyway. This problem actually came up in real code (singletons library), where I'm trying to get the generated code to be warning-free. This was tested on 7.7.20131031. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8499> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8500: Default associated type instances not instantiated
by GHC 06 Nov '13

06 Nov '13

#8500: Default associated type instances not instantiated ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I have these modules: {{{ {-# LANGUAGE TypeFamilies #-} module A where class C a where type F a type F a = [a] }}} {{{ {-# LANGUAGE TypeFamilies #-} module B where import A instance C Int where type F Int = Double instance C Bool }}} When I say `ghc A.hs B.hs`, all works just fine. But, if I say `ghc A.hs` and then `ghc B.hs`, I get this: {{{ B.hs:8:8: Conflicting family instance declarations: F Int -- Defined at B.hs:8:8 F a1 -- Defined in ‛B’ }}} For some reason, when GHC reads in default type instances from an interface file, it doesn't instantiate them properly when they get used. This was tested on 7.7.20131031. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8500> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5013: sporadic failures during compilation under solaris
by GHC 05 Nov '13

05 Nov '13

#5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by maeder): I've replaced `throwErrnoPathIfMinus1_` with `throwErrnoPathIfMinus1Retry_` (also in `libraries/unix/System/Posix/Files/ByteString.hsc`) to see if this makes a difference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5013#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7346: Allow the use of `deriving` for GHC generics
by GHC 05 Nov '13

05 Nov '13

#7346: Allow the use of `deriving` for GHC generics -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 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 ghorn): * cc: gregmainland@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7346#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1480: Template Haskell should allow reification of modules
by GHC 05 Nov '13

05 Nov '13

#1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonpj): Got it. I'll add comments. I agree about not using `mi_usages` for Gergely's purposes. Maybe add `dep_dir_imps :: [Module]` to `Dependencies` to record the directly- imported modules? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1480#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1480: Template Haskell should allow reification of modules
by GHC 05 Nov '13

05 Nov '13

#1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonmar): Now that I think about it, I'm wary about using `mi_usages` for reification, because that widens its scope beyond the recompilation checker. It seems more correct to add the information to `mi_deps`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1480#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1480: Template Haskell should allow reification of modules
by GHC 05 Nov '13

05 Nov '13

#1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonmar): Replying to [comment:24 simonpj]: > Simon, I don't understand the relationship between `mi_deps` and `mi_usages` fields of `ModIface`. Both seem implicated in the recompilation check. Can you clarify? I've just been poking around in the source tree and the wiki, and I think a concise summary is this: `mi_deps` lists everything below the module, whereas `mi_usages` lists the bits that the module actually depends on, and their fingerprints. `mi_usages` is used ''only'' by the recompilation checker, whereas `mi_deps` is used by the renamer and other places (linking?), and by the recompilation checker. The `mi_usages` of modules that we are not compiling are completely redundant, we never even load them - the interface deserializer returns a thunk for that bit of the `.hi` file, and we never look at it. There is some overlap between these two fields. As far as I know it's been this way for a long time - since before I implemented fingerprints I think. Perhaps the redundancy could be eliminated... but there are a lot of subtleties here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1480#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0