[GHC] #5709: ghc-7.2 cannot find libraries in non-standard locations

[GHC]

#5709: ghc-7.2 cannot find libraries in non-standard locations
--+-
 Reporter:  kosmikus  |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Package system  
  Version:  7.2.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  Other |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
 The following is what I perceive to be a regression from ghc-7.0.4 to
 ghc-7.2.1 and ghc-7.2.2.

 On NixOS, all packages are installed into separate directories in the Nix
 store. With ghc-7.0.4, the following works:
 {{{
 $ ghc -package zlib -e "print ()"
 ()
 $ ghc-pkg describe zlib | grep library-dirs -A 1
 library-dirs: /nix/store/vnflri0w0fadiqwv1j6w6gxw00paav6a-haskell-zlib-
 ghc7.0.4-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.0.4
   /nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib
 $ strace ghc -package zlib -e "print ()" 2>&1 | grep libz.so
 stat64("/nix/store/vnflri0w0fadiqwv1j6w6gxw00paav6a-haskell-zlib-
 ghc7.0.4-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.0.4/libz.so",
 0xb5e94490) = -1 ENOENT (No such file or directory)
 stat64("/nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-
 zlib-1.2.5/lib/libz.so", {st_mode=S_IFREG|0555, st_size=91092, ...}) = 0
 open("/nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib/libz.so",
 O_RDONLY) = 7
 }}}

 However, if I try exactly the same with ghc-7.2.1, I get:
 {{{
 $ ghc -package zlib -e "print ()"
 : can't load .so/.DLL for: libz.so (libz.so: cannot open
 shared object file: No such file or directory)
 $ ghc-pkg describe zlib | grep library-dirs -A 1
 library-dirs: /nix/store/6zjd86g35dpxl5r6zrr67nnmf00qalkr-haskell-zlib-
 ghc7.2.1-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.2.1
   /nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib
 $ strace ghc -package zlib -e "print ()" 2>&1 | grep libz.so
 open("/nix/store/ri2nlzb1lsi0d1y7nb8dkhzhsnyd08k4-gmp-4.3.2/lib/libz.so",
 O_RDONLY) = -1 ENOENT (No such file or directory)
 open("/nix/store/nmliqd429c0s4sdlbk0394zdfx86gvf9-ncurses-5.7/lib/libz.so",
 O_RDONLY) = -1 ENOENT (No such file or directory)
 open("/nix/store/m9p1r0p6qlaw5wy5hnwpii323la3s8j3-glibc-2.12.2/lib/libz.so",
 O_RDONLY) = -1 ENOENT (No such file or directory)
 open("/nix/store/m9p1r0p6qlaw5wy5hnwpii323la3s8j3-glibc-2.12.2/lib/libz.so",
 O_RDONLY) = -1 ENOENT (No such file or directory)
 }}}
 The directories listed by strace seem to be the ones used for building GHC
 itself. The directories in the package configuration file seem to be
 ignored.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5691: Crash: strange interaction of ScopedTypeVariables extension with type class name resolution

[GHC]

#5691: Crash: strange interaction of ScopedTypeVariables extension with type 
class
name resolution
--+-
  Reporter:  dominiquedevriese|  Owner: 
  
  Type:  bug  | Status:  closed 
  
  Priority:  normal   |  Milestone: 
  
 Component:  Compiler (Type checker)  |Version:  7.0.4  
  
Resolution:  fixed|   Keywords:  
ScopedTypeVariables, type classes
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple   
  
   Failure:  Compile-time crash   | Difficulty:  Unknown
  
  Testcase:  typecheck/should_fail/T5691  |  Blockedby: 
  
  Blocking:   |Related: 
  
--+-

Comment(by dominiquedevriese):

 Great to know that it's fixed, thanks for taking a look.

 Dominique

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5467: Template Haskell: support for Haddock comments

[GHC]

#5467: Template Haskell: support for Haddock comments
-+--
Reporter:  reinerp   |   Owner:  
Type:  feature request   |  Status:  new 
Priority:  normal|   Milestone:  7.6.1   
   Component:  Template Haskell  | Version:  7.2.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:|Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by PHO):

 * cc: pho@… (added)


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5708: Qualified name in binding position

[GHC]

#5708: Qualified name in binding position
--+-
 Reporter:  fryguybob |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Compiler
  Version:|   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
Changes (by byorgey):

 * cc: byorgey@… (added)


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #5708: Qualified name in binding position

[GHC]

#5708: Qualified name in binding position
--+-
 Reporter:  fryguybob |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Compiler
  Version:|   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
 When building `diagrams` with HEAD I ran into this difference from 7.0.2
 (and I believe 7.2) shown with this:

 {{{
  Qual.hs 

 {-# LANGUAGE TypeFamilies #-}

 import qualified Blah.A as A

 instance A.B Int where
   type A.T Int = Bool
 }}}

 {{{
  Blah/A.hs 

 {-# LANGUAGE TypeFamilies #-}

 module Blah.A (B(..)) where

 class B a where
   type T a :: *
 }}}

 {{{
 --- Output from HEAD (was same with 7.3.20111206)
 $ ~/ghc/inplace/bin/ghc-stage2 --interactive Qual.hs
 GHCi, version 7.5.20111215: http://www.haskell.org/ghc/  :? for help
 Loading package ghc-prim ... linking ... done.
 Loading package integer-gmp ... linking ... done.
 Loading package base ... linking ... done.
 [1 of 2] Compiling Blah.A   ( Blah/A.hs, interpreted )
 [2 of 2] Compiling Main ( Qual.hs, interpreted )

 Qual.hs:6:8: Qualified name in binding position: A.T
 Failed, modules loaded: Blah.A.
 *Blah.A>
 }}}

 {{{
  Output from 7.0.2
 $ ghci Qual.hs
 GHCi, version 7.0.2: http://www.haskell.org/ghc/  :? for help
 Loading package ghc-prim ... linking ... done.
 Loading package integer-gmp ... linking ... done.
 Loading package base ... linking ... done.
 [1 of 2] Compiling Blah.A   ( Blah/A.hs, interpreted )
 [2 of 2] Compiling Main ( qual.hs, interpreted )
 Ok, modules loaded: Blah.A, Main.
 *Main>
 }}}

 In our case we didn't need the qualified import anyway and removed it
 here:  http://www.patch-tag.com/r/byorgey/diagrams-
 
core/snapshot/hash/20111215185451-1e371-dcaeff70fc825e9afa91addbeaaa69c5749f5529/patch

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5707: internal error: Invalid object in processHeapClosureForDead(): 0

[GHC]

#5707: internal error: Invalid object in processHeapClosureForDead(): 0
---+
 Reporter:  brinchj|  Owner:
 Type:  bug| Status:  new   
 Priority:  normal |  Component:  Compiler  
  Version:  7.2.1  |   Keywords:  biographical profiling
   Os:  Linux  |   Architecture:  x86_64 (amd64)
  Failure:  Runtime crash  |   Testcase:
Blockedby: |   Blocking:
  Related:  5451, 1519 |  
---+
Changes (by brinchj):

  * failure:  None/Unknown => Runtime crash
  * os:  Unknown/Multiple => Linux


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #5707: internal error: Invalid object in processHeapClosureForDead(): 0

[GHC]

#5707: internal error: Invalid object in processHeapClosureForDead(): 0
--+-
 Reporter:  brinchj   |  Owner:
 Type:  bug   | Status:  new   
 Priority:  normal|  Component:  Compiler  
  Version:  7.2.1 |   Keywords:  biographical profiling
   Os:  Unknown/Multiple  |   Architecture:  x86_64 (amd64)
  Failure:  None/Unknown  |   Testcase:
Blockedby:|   Blocking:
  Related:  5451, 1519|  
--+-
 I can't figure out if this has been fixed in 7.3 .. anyway, better safe
 than sorry, so here goes.

 I get this error with biographical profiling (like #5451 and #1519, i
 guess). It's present in both 7.2.1 and 7.2.2 - haven't tried 7.3 or 7.4.

 Just let me know if this is a fixed issue or not, and I'll see if I can
 provide a test case (it's not a completely trivial I'm trying to profile
 program).

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5705: getGCStats only works with +RTS -s

[GHC]

#5705: getGCStats only works with +RTS -s
--+-
 Reporter:  tibbe |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Runtime System  
  Version:  7.2.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-

Comment(by ezyang):

 Yes, this is because the information is collected from GC statistics (note
 that you actually probably want -T, because that results in no extra
 output.)

 I'm pretty sure this is WONTFIX, because GC statistics impose nontrivial
 overhead. Something that I've been meaning to do but haven't yet is have
 the function throw an exception if stats are not available.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5691: Crash: strange interaction of ScopedTypeVariables extension with type class name resolution

[GHC]

#5691: Crash: strange interaction of ScopedTypeVariables extension with type 
class
name resolution
--+-
  Reporter:  dominiquedevriese|  Owner: 
  
  Type:  bug  | Status:  closed 
  
  Priority:  normal   |  Milestone: 
  
 Component:  Compiler (Type checker)  |Version:  7.0.4  
  
Resolution:  fixed|   Keywords:  
ScopedTypeVariables, type classes
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple   
  
   Failure:  Compile-time crash   | Difficulty:  Unknown
  
  Testcase:  typecheck/should_fail/T5691  |  Blockedby: 
  
  Blocking:   |Related: 
  
--+-
Changes (by simonpj):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => fixed
  * testcase:  => typecheck/should_fail/T5691


Comment:

 Interesting!  Indeed with 7.0.3 I get
 {{{
 simonpj@cam-04-unx:~/tmp$ ghc-7.0.3 -c T5691.hs -dcore-lint
 *** Core Lint errors : in result of Desugar ***
 :
 In the coercion `co_alI'
 co_alI is out of scope
 *** Offending Program ***
  ...snip...
 }}}
 But with HEAD I get
 {{{
 T5691.hs:15:24:
 Couldn't match type `p' with `PrintRuleInterp'
 Expected type: PrintRuleInterp a
   Actual type: p a
 In the first argument of `printRule_', namely `f'
 In the second argument of `($)', namely `printRule_ f'
 In the expression: MkPRI $ printRule_ f

 T5691.hs:24:10:
 No instance for (Monad RecDecParser)
   arising from the superclasses of an instance declaration
 Possible fix: add an instance declaration for (Monad RecDecParser)
 In the instance declaration for `MonadPlus RecDecParser'
 }}}
 both of which are correct.  Rather than investigate further, I'll mark
 this as fixed, but I'll add it to the test suite.

 Thanks

 simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5684: ghc: panic! (the 'impossible' happened) (ghc 7.2.2)

[GHC]

#5684: ghc: panic! (the 'impossible' happened) (ghc 7.2.2)
---+
Reporter:  selinger|Owner:  
  
Type:  bug |   Status:  closed  
  
Priority:  normal  |Component:  Compiler
  
 Version:  7.2.1   |   Resolution:  fixed   
  
Keywords:  |   Os:  
Unknown/Multiple  
Architecture:  Unknown/Multiple|  Failure:  Compile-time 
crash
Testcase:  typecheck/should_fail/T5684.hs  |Blockedby:  
  
Blocking:  |  Related:  
  
---+
Changes (by dimitris):

  * status:  new => closed
  * testcase:  => typecheck/should_fail/T5684.hs
  * resolution:  => fixed


Comment:

 Thanks for the feedback. There were two things wrong in 7.2.1:
   - An assertion was just false because of a broken invariant
   - But, the assertion was hidden under a thunk and got triggered not at
 the right place, potentially under random poking from who-knows-who.

 Now, in HEAD by construction this invariant is true (so the real bug you
 observed no longer manifests there). But the assertion is still there so I
 did push a patch that makes the assertion trigger aggressively.

 The test is in typecheck/should_fail/T5684.hs
 and the comments in that test describe the problem in more technical
 terms.

 The relevant commit is:

 commit bd13338da1649600b6a63ae7cbf60a35575940dc
 Author: Dimitrios Vytiniotis 
 Date:   Thu Dec 15 14:18:31 2011 +

 Exposing a useful assertion which was hidden inside a lazyness cloud.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #5706: building ghc from source tarball requires alex?

[GHC]

#5706: building ghc from source tarball requires alex?
-+--
 Reporter:  kosmikus |  Owner:  
 Type:  bug  | Status:  new 
 Priority:  normal   |  Component:  Build System
  Version:  7.3  |   Keywords:  
   Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
  Failure:  Building GHC failed  |   Testcase:  
Blockedby:   |   Blocking:  
  Related:   |  
-+--
 Building a recent GHC snapshot via my usual Nix expression for doing this
 resulted in an error:
 {{{
 building utils/haddock/dist/package-data.mk
 "inplace/bin/ghc-cabal" configure --with-ghc="/tmp/nix-build-
 j66qzyg325kggqaj69vmmfgvq54cg83y-
 ghc-7.3.20111212.drv-0/ghc-7.3.20111212/inplace/bin/ghc-stage1" --with-
 ghc-pkg="/tmp/nix-build-j66qzyg325kggqaj69vmmfgvq54cg83y-
 ghc-7.3.20111212.drv-0/ghc-7.3.20111212/inplace/bin/ghc-pkg" --flag in-
 ghc-tree --enable-library-profiling --enable-shared --enable-library-for-
 ghci --configure-option=CFLAGS=" -fno-stack-protector  " --configure-
 option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads  "
 --configure-option=CPPFLAGS="   " --with-gcc="/nix/store
 /2yghakb86zfivd2da4x1ipcz03xmz6rd-gcc-wrapper-4.5.1/bin/gcc" --configure-
 option=--with-cc="/nix/store/2yghakb86zfivd2da4x1ipcz03xmz6rd-gcc-
 wrapper-4.5.1/bin/gcc" --with-ar="/nix/store
 /9b3q62czfh5zld9zg2p8sbk65hkbvpzi-binutils-2.21/bin/ar" --with-
 ranlib="true" -- dist utils/haddock
 Configuring haddock-2.9.4...
 ghc-cabal: The program alex version >=2.3 is required but it could not be
 found.
 make[1]: *** [utils/haddock/dist/package-data.mk] Error 1
 [qmake: *** [all] Error 2
 [q[q[qbuilder for `/nix/store/j66qzyg325kggqaj69vmmfgvq54cg83y-
 ghc-7.3.20111212.drv' failed; keeping build directory `/tmp/nix-build-
 j66qzyg325kggqaj69vmmfgvq54cg83y-ghc-7.3.20111212.drv-0'
 builder for `/nix/store/j66qzyg325kggqaj69vmmfgvq54cg83y-
 ghc-7.3.20111212.drv' failed with exit code 2
 cannot build derivation `/nix/store/gmllr5nfxlxw2cfvmvfymk3y6q9qzdlv-
 ghc-7.3.20111212-wrapper.drv': 1 dependencies couldn't be built
 error: build of `/nix/store/gmllr5nfxlxw2cfvmvfymk3y6q9qzdlv-
 ghc-7.3.20111212-wrapper.drv' failed
 }}}

 The requirement for alex seems new. At least I know that the same Nix
 expression successfully built older (i.e., 7.1) snapshots. Is alex really
 required to build from a source tarball?

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5705: getGCStats only works with +RTS -s

[GHC]

#5705: getGCStats only works with +RTS -s
--+-
 Reporter:  tibbe |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Runtime System  
  Version:  7.2.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
Description changed by tibbe:

Old description:

> As the below program shows, `GHC.Stats.getGCStats` only returns non-zero
> values for e.g. `gc_wall_time` if the program is run with `+RTS -s`. I
> guess that's because the stats aren't tracked by the GC unless you
> specify `+RTS -s`. Are the stats expensive to maintain? If not could we
> always update these counters?
>
> {{{
> module Main where
>
> import GHC.Stats
> import System.Mem
>
> main = do
> print $ let xs = [1..100]  -- allocation
> in fromIntegral (sum xs) / fromIntegral (length xs)
> performGC
> stats <- getGCStats
> putStrLn $ show stats
> }}}
>
> {{{
> $ ./Repro
> 50.5
> GCStats {bytesAllocated = 0, numGcs = 184, maxBytesUsed = 0,
> numByteUsageSamples = 0, cumulativeBytesUsed = 0, bytesCopied = 0,
> currentBytesUsed = 0, currentBytesSlop = 0, maxBytesSlop = 0,
> peakMegabytesAllocated = 63, mutatorCpuSeconds = 9.6468e-2,
> mutatorWallSeconds = 0.115874, gcCpuSeconds = 0.0,
> gcWallSeconds = 0.0, cpuSeconds = 9.7045e-2, wallSeconds = 0.115874,
> parAvgBytesCopied = 0, parMaxBytesCopied = 0}
> }}}
>
> {{{
> 50.5
> GCStats {bytesAllocated = 96086504, numGcs = 184, maxBytesUsed =
> 27442272,
> numByteUsageSamples = 7, cumulativeBytesUsed = 52228768, bytesCopied =
> 90580024,
> currentBytesUsed = 74336, currentBytesSlop = 0, maxBytesSlop = 6803872,
> peakMegabytesAllocated = 63, mutatorCpuSeconds = 2.523e-2,
> mutatorWallSeconds = 2.5739e-2, gcCpuSeconds = 7.1919e-2,
> gcWallSeconds = 9.126e-2, cpuSeconds = 9.7729e-2, wallSeconds = 0.116999,
> parAvgBytesCopied = 0, parMaxBytesCopied = 0}
> ...
> }}}

New description:

 As the below program shows, `GHC.Stats.getGCStats` only returns non-zero
 values for e.g. `gc_wall_time` if the program is run with `+RTS -s`. I
 guess that's because the stats aren't tracked by the GC unless you specify
 `+RTS -s`. Are the stats expensive to maintain? If not could we always
 update these counters?

 {{{
 module Main where

 import GHC.Stats
 import System.Mem

 main = do
 print $ let xs = [1..100]  -- allocation
 in fromIntegral (sum xs) / fromIntegral (length xs)
 performGC
 stats <- getGCStats
 putStrLn $ show stats
 }}}

 {{{
 $ ./Repro
 50.5
 GCStats {bytesAllocated = 0, numGcs = 184, maxBytesUsed = 0,
 numByteUsageSamples = 0, cumulativeBytesUsed = 0, bytesCopied = 0,
 currentBytesUsed = 0, currentBytesSlop = 0, maxBytesSlop = 0,
 peakMegabytesAllocated = 63, mutatorCpuSeconds = 9.6468e-2,
 mutatorWallSeconds = 0.115874, gcCpuSeconds = 0.0,
 gcWallSeconds = 0.0, cpuSeconds = 9.7045e-2, wallSeconds = 0.115874,
 parAvgBytesCopied = 0, parMaxBytesCopied = 0}
 }}}

 {{{
 $ ./Repro +RTS -s
 50.5
 GCStats {bytesAllocated = 96086504, numGcs = 184, maxBytesUsed = 27442272,
 numByteUsageSamples = 7, cumulativeBytesUsed = 52228768, bytesCopied =
 90580024,
 currentBytesUsed = 74336, currentBytesSlop = 0, maxBytesSlop = 6803872,
 peakMegabytesAllocated = 63, mutatorCpuSeconds = 2.523e-2,
 mutatorWallSeconds = 2.5739e-2, gcCpuSeconds = 7.1919e-2,
 gcWallSeconds = 9.126e-2, cpuSeconds = 9.7729e-2, wallSeconds = 0.116999,
 parAvgBytesCopied = 0, parMaxBytesCopied = 0}
 ...
 }}}

--

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #5705: getGCStats only works with +RTS -s

[GHC]

#5705: getGCStats only works with +RTS -s
--+-
 Reporter:  tibbe |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Runtime System  
  Version:  7.2.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
 As the below program shows, `GHC.Stats.getGCStats` only returns non-zero
 values for e.g. `gc_wall_time` if the program is run with `+RTS -s`. I
 guess that's because the stats aren't tracked by the GC unless you specify
 `+RTS -s`. Are the stats expensive to maintain? If not could we always
 update these counters?

 {{{
 module Main where

 import GHC.Stats
 import System.Mem

 main = do
 print $ let xs = [1..100]  -- allocation
 in fromIntegral (sum xs) / fromIntegral (length xs)
 performGC
 stats <- getGCStats
 putStrLn $ show stats
 }}}

 {{{
 $ ./Repro
 50.5
 GCStats {bytesAllocated = 0, numGcs = 184, maxBytesUsed = 0,
 numByteUsageSamples = 0, cumulativeBytesUsed = 0, bytesCopied = 0,
 currentBytesUsed = 0, currentBytesSlop = 0, maxBytesSlop = 0,
 peakMegabytesAllocated = 63, mutatorCpuSeconds = 9.6468e-2,
 mutatorWallSeconds = 0.115874, gcCpuSeconds = 0.0,
 gcWallSeconds = 0.0, cpuSeconds = 9.7045e-2, wallSeconds = 0.115874,
 parAvgBytesCopied = 0, parMaxBytesCopied = 0}
 }}}

 {{{
 50.5
 GCStats {bytesAllocated = 96086504, numGcs = 184, maxBytesUsed = 27442272,
 numByteUsageSamples = 7, cumulativeBytesUsed = 52228768, bytesCopied =
 90580024,
 currentBytesUsed = 74336, currentBytesSlop = 0, maxBytesSlop = 6803872,
 peakMegabytesAllocated = 63, mutatorCpuSeconds = 2.523e-2,
 mutatorWallSeconds = 2.5739e-2, gcCpuSeconds = 7.1919e-2,
 gcWallSeconds = 9.126e-2, cpuSeconds = 9.7729e-2, wallSeconds = 0.116999,
 parAvgBytesCopied = 0, parMaxBytesCopied = 0}
 ...
 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5108: Allow unicode sub/superscript symbols in both identifiers and operators

[GHC]

#5108: Allow unicode sub/superscript symbols in both identifiers and operators
---+
Reporter:  mikhail.vorozhtsov  |   Owner:  
Type:  feature request |  Status:  patch   
Priority:  normal  |   Milestone:  7.4.1   
   Component:  Compiler (Parser)   | Version:  7.1 
Keywords:  lexer unicode   |  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple| Failure:  None/Unknown
  Difficulty:  Unknown |Testcase:  
   Blockedby:  |Blocking:  
 Related:  |  
---+
Changes (by simonmar):

  * difficulty:  => Unknown


Comment:

 I'm not keen on this patch for a few reasons:

  * It's inconsistent to allow superscript/subscript on symbols.  Haskell
doesn't currently allow primes on symbols, for example.

  * The patch has a bunch of Unicode constants baked into it

  * It adds a bunch of extra tests to the inner loop.  I haven't
measured it but I wouldn't be surprised if this slows down the lexer.

 Perhaps it might be better just to allow the category Lm (MODIFIER LETTER)
 as part of an identifier?  That would include all the primes and
 subscript/superscript things.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

RE: [GHC] #5539: GHC panic - Simplifier ticks exhausted

[Simon Peyton-Jones]

Ian,

Could you look at the reported simplifier-ticks-exhausted bugs, and increase 
the multiplier in SimplMonad line 93 until they are all ok.  Then assign the 
tickets to me (perhaps link them), because I want to see why they are high.  
Maybe there is something interesting going on.

Thanks

Simon

| -Original Message-
| From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs-
| boun...@haskell.org] On Behalf Of GHC
| Sent: 15 December 2011 12:01
| Cc: glasgow-haskell-bugs@haskell.org
| Subject: Re: [GHC] #5539: GHC panic - Simplifier ticks exhausted
| 
| #5539: GHC panic -  Simplifier ticks exhausted
| -+--
|   Reporter:  hvr |  Owner:  simonpj
|   Type:  bug | Status:  new
|   Priority:  normal  |  Milestone:  7.4.1
|  Component:  Compiler|Version:  7.3
| Resolution:  |   Keywords:
| Os:  Linux   |   Architecture:  x86_64 (amd64)
|Failure:  Compile-time crash  | Difficulty:
|   Testcase:  |  Blockedby:
|   Blocking:  |Related:
| -+--
| 
| Comment(by tibbe):
| 
|  Could we please bump the priority of this ticket? Large swats of packages
|  don't build due to vector not building.
| 
| --
| Ticket URL: 
| GHC 
| The Glasgow Haskell Compiler
| 
| ___
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs



___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5704: Bug in the handling of wired-in packages (like template-haskell)

[GHC]

#5704: Bug in the handling of wired-in packages (like template-haskell)
-+--
Reporter:  simonmar  |   Owner:  
Type:  bug   |  Status:  new 
Priority:  high  |   Milestone:  7.4.1   
   Component:  Package system| Version:  7.2.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by tibbe):

 Just to clarify the actual failure case:

  * `aeson-0.4.0.0` requires `template-haskell` >= 2.4,
  * `snap-server-0.7.1` requires `template-haskell` >= 2.2 && < 2.7,
  * `template-haskell-2.6.0.0` therefore gets selected, and
  * the compilation (of `aeson`) fails as in the ticket description.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #5704: Bug in the handling of wired-in packages (like template-haskell)

[GHC]

#5704: Bug in the handling of wired-in packages (like template-haskell)
-+--
Reporter:  simonmar  |   Owner:  
Type:  bug   |  Status:  new 
Priority:  high  |   Milestone:  7.4.1   
   Component:  Package system| Version:  7.2.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
 If you install an older version of a wired-in package (e.g. template-
 haskell) and then try to use it, GHC will use the newer one as the "wired-
 in" package rather than the older one.

 This happened when trying to build `aeson-0.4.0.0` with ghc 7.4: `aeson`
 requires `template-haskell-2.6.0.0`, but GHC ships with 2.7.0.0.  Cabal
 installed `template-haskell-2.6.0.0`, but while building `aeson` against
 it we get:

 {{{
 Data/Aeson/TH.hs:181:1:
 Bad interface file: /Users/tibbe/.cabal/lib/template-
 haskell-2.6.0.0/ghc-7.4.0.20111213/Language/Haskell/TH.hi
 Something is amiss; requested module  template-
 haskell-2.6.0.0:Language.Haskell.TH differs from name found in the
 interface file template-haskell:Language.Haskell.TH
 }}}

 the bug is that `findWiredInPackage` has picked `template-haskell-2.7.0.0`
 to be the wired-in package:

 {{{
 wired-in package template-haskell mapped to template-
 haskell-2.7.0.0-inplace
 }}}

 whereas we wanted to use `template-haskell-2.6.0.0`.

 Not immediately obvious what the fix should be, so I'm making a ticket for
 this.  The workaround is to update the dependency in `aeson` to allow
 `template-haskell-2.7.0.0`.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5539: GHC panic - Simplifier ticks exhausted

[GHC]

#5539: GHC panic -  Simplifier ticks exhausted
-+--
  Reporter:  hvr |  Owner:  simonpj   
  Type:  bug | Status:  new   
  Priority:  high|  Milestone:  7.4.1 
 Component:  Compiler|Version:  7.3   
Resolution:  |   Keywords:
Os:  Linux   |   Architecture:  x86_64 (amd64)
   Failure:  Compile-time crash  | Difficulty:  Unknown   
  Testcase:  |  Blockedby:
  Blocking:  |Related:
-+--
Changes (by simonmar):

  * priority:  normal => high
  * difficulty:  => Unknown


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5539: GHC panic - Simplifier ticks exhausted

[GHC]

#5539: GHC panic -  Simplifier ticks exhausted
-+--
  Reporter:  hvr |  Owner:  simonpj   
  Type:  bug | Status:  new   
  Priority:  normal  |  Milestone:  7.4.1 
 Component:  Compiler|Version:  7.3   
Resolution:  |   Keywords:
Os:  Linux   |   Architecture:  x86_64 (amd64)
   Failure:  Compile-time crash  | Difficulty:
  Testcase:  |  Blockedby:
  Blocking:  |Related:
-+--

Comment(by tibbe):

 See also #5703

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5703: vector fails to compile due to simplifier ticks exhausted

[GHC]

#5703: vector fails to compile due to simplifier ticks exhausted
-+--
Reporter:  tibbe |Owner:  
Type:  bug   |   Status:  closed  
Priority:  normal|Component:  Compiler
 Version:  7.3   |   Resolution:  duplicate   
Keywords:|   Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
Testcase:|Blockedby:  
Blocking:|  Related:  
-+--
Changes (by tibbe):

  * status:  new => closed
  * resolution:  => duplicate


Comment:

 Duplicate of #5539

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5539: GHC panic - Simplifier ticks exhausted

[GHC]

#5539: GHC panic -  Simplifier ticks exhausted
-+--
  Reporter:  hvr |  Owner:  simonpj   
  Type:  bug | Status:  new   
  Priority:  normal  |  Milestone:  7.4.1 
 Component:  Compiler|Version:  7.3   
Resolution:  |   Keywords:
Os:  Linux   |   Architecture:  x86_64 (amd64)
   Failure:  Compile-time crash  | Difficulty:
  Testcase:  |  Blockedby:
  Blocking:  |Related:
-+--

Comment(by tibbe):

 Could we please bump the priority of this ticket? Large swats of packages
 don't build due to vector not building.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #5703: vector fails to compile due to simplifier ticks exhausted

[GHC]

#5703: vector fails to compile due to simplifier ticks exhausted
--+-
 Reporter:  tibbe |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Compiler
  Version:  7.3   |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
 I thought the limit was raised in 7.4 but vector still fails to compile
 using the current ghc-7.4 branch:

 {{{
 Configuring vector-algorithms-0.5.3...
 Preprocessing library vector-algorithms-0.5.3...
 Building vector-algorithms-0.5.3...
 [1 of 9] Compiling Data.Vector.Algorithms.Common (
 Data/Vector/Algorithms/Common.hs,
 dist/build/Data/Vector/Algorithms/Common.o )
 [2 of 9] Compiling Data.Vector.Algorithms.Radix (
 Data/Vector/Algorithms/Radix.hs, dist/build/Data/Vector/Algorithms/Radix.o
 )
 [3 of 9] Compiling Data.Vector.Algorithms.Search (
 Data/Vector/Algorithms/Search.hs,
 dist/build/Data/Vector/Algorithms/Search.o )
 [4 of 9] Compiling Data.Vector.Algorithms.Optimal (
 Data/Vector/Algorithms/Optimal.hs,
 dist/build/Data/Vector/Algorithms/Optimal.o )
 [5 of 9] Compiling Data.Vector.Algorithms.Insertion (
 Data/Vector/Algorithms/Insertion.hs,
 dist/build/Data/Vector/Algorithms/Insertion.o )
 [6 of 9] Compiling Data.Vector.Algorithms.AmericanFlag (
 Data/Vector/Algorithms/AmericanFlag.hs,
 dist/build/Data/Vector/Algorithms/AmericanFlag.o )
 [7 of 9] Compiling Data.Vector.Algorithms.Heap (
 Data/Vector/Algorithms/Heap.hs, dist/build/Data/Vector/Algorithms/Heap.o )
 [8 of 9] Compiling Data.Vector.Algorithms.Intro (
 Data/Vector/Algorithms/Intro.hs, dist/build/Data/Vector/Algorithms/Intro.o
 )
 ghc-stage2: panic! (the 'impossible' happened)
   (GHC version 7.4.0.20111213 for x86_64-apple-darwin):
 Simplifier ticks exhausted
 When trying UnfoldingDone ( ghc-prim:GHC.Classes.||{v r1c} [gid] ::
 ghc-prim:GHC.Types.Bool{(w) tc 3c}
 ->
 ghc-prim:GHC.Types.Bool{(w) tc 3c}
 ->
 ghc-prim:GHC.Types.Bool{(w) tc 3c} )
 To increase the limit, use -fsimpl-tick-factor=N (default 100)
 If you need to do this, let GHC HQ know, and what factor you needed
 To see detailed counts use -ddump-simpl-stats
 Total ticks: 46921

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #888: Implement the static argument transformation

[GHC]

#888: Implement the static argument transformation
-+--
Reporter:  simonpj   |   Owner:  
Type:  task  |  Status:  new 
Priority:  low   |   Milestone:  7.4.1   
   Component:  Compiler  | Version:  6.4.2   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  N/A 
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by choenerzs):

 * cc: choener@… (added)


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs