- Glasgow-haskell-users

Cannot install 8.0.1 from bindist
by Peter 25 May '16

25 May '16

Trying to install ghc-8.0.1-x86_64-centos67-linux.tar.xz with: ./configure --prefix={prefix} make install-strip gives me an error. The tail of the log is: Registering ghc-8.0.1... for f in '{prefix}/lib/ghc-8.0.1/package.conf.d'/*; do create () { touch "$1" && chmod 644 "$1" ; } && create "$f"; done /usr/bin/install -c -m 755 -d "{prefix}/bin" for i in utils/hp2ps/dist/build/tmp/hp2ps; do \ /usr/bin/install -c -m 755 -s $i "{prefix}/bin" ; \ done /usr/bin/install -c -m 755 -d "{prefix}/lib/ghc-8.0.1/bin" for i in inplace/lib/bin/ghc-split; do \ /usr/bin/install -c -m 755 $i "{prefix}/lib/ghc-8.0.1/bin"; \ done /usr/bin/install -c -m 755 -d "{prefix}/share/doc/ghc-8.0.1" /usr/bin/install -c -m 755 -d "{prefix}/share/doc/ghc-8.0.1/html" /usr/bin/install -c -m 644 docs/index.html "{prefix}/share/doc/ghc-8.0.1/html" /usr/bin/install -c -m 755 -d "{prefix}/share/doc/ghc-8.0.1/html/libraries" for i in libraries/dist-haddock/*; do \ /usr/bin/install -c -m 644 $i "{prefix}/share/doc/ghc-8.0.1/html/libraries/"; \ done /usr/bin/install -c -m 644 libraries/prologue.txt "{prefix}/share/doc/ghc-8.0.1/html/libraries/" /usr/bin/install -c -m 755 libraries/gen_contents_index "{prefix}/share/doc/ghc-8.0.1/html/libraries/" mkdir: cannot create directory `doc/aries/ghc-prim-0.5.0.0': No such file or directory Is there any way of knowing what the call to mkdir is relative to, and why it's trying to create the directory there? -- View this message in context: http://haskell.1045720.n5.nabble.com/Cannot-install-8-0-1-from-bindist-tp58… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

2 2

suboptimal ghc code generation in IO vs equivalent pure code case
by Harendra Kumar 16 May '16

16 May '16

I have a loop which runs millions of times. For some reason I have to run it in the IO monad. I noticed that when I convert the code from pure to IO monad the generated assembly code in essence is almost identical except one difference where it puts a piece of code in a separate block which is making a huge difference in performance (4-6x slower). I want to understand what makes GHC to generate code in this way and if there is anything that can be done at source level (or ghc option) to control that. The pure code looks like this: decomposeChars :: [Char] -> [Char] decomposeChars [] = [] decomposeChars [x] = case NFD.isDecomposable x of True -> decomposeChars (NFD.decomposeChar x) False -> [x] decomposeChars (x : xs) = decomposeChars [x] ++ decomposeChars xs The equivalent IO code is this: decomposeStrIO :: [Char] -> IO [Char] decomposeStrPtr !p = decomposeStrIO where decomposeStrIO [] = return [] decomposeStrIO [x] = do res <- NFD.isDecomposable p x case res of True -> decomposeStrIO (NFD.decomposeChar x) False -> return [x] decomposeStrIO (x : xs) = do s1 <- decomposeStrIO [x] s2 <- decomposeStrIO xs return (s1 ++ s2) The difference is in how the code corresponding to the call to the (++) operation is generated. In the pure case the (++) operation is inline in the main loop: _cn5N: movq $sat_sn2P_info,-48(%r12) movq %rax,-32(%r12) movq %rcx,-24(%r12) movq $:_con_info,-16(%r12) movq 16(%rbp),%rax movq %rax,-8(%r12) movq $GHC.Types.[]_closure+1,(%r12) leaq -48(%r12),%rsi leaq -14(%r12),%r14 addq $40,%rbp jmp GHC.Base.++_info In the IO monad version this code is placed in a separate block and a call is placed in the main loop: the main loop call site: _cn6A: movq $sat_sn3w_info,-24(%r12) movq 8(%rbp),%rax movq %rax,-8(%r12) movq %rbx,(%r12) leaq -24(%r12),%rbx addq $40,%rbp jmp *(%rbp) out of the line block - the code that was in the main loop in the previous case is now moved to this block (see label _cn5s below): sat_sn3w_info: _cn5p: leaq -16(%rbp),%rax cmpq %r15,%rax jb _cn5q _cn5r: addq $24,%r12 cmpq 856(%r13),%r12 ja _cn5t _cn5s: movq $stg_upd_frame_info,-16(%rbp) movq %rbx,-8(%rbp) movq 16(%rbx),%rax movq 24(%rbx),%rbx movq $:_con_info,-16(%r12) movq %rax,-8(%r12) movq $GHC.Types.[]_closure+1,(%r12) movq %rbx,%rsi leaq -14(%r12),%r14 addq $-16,%rbp jmp GHC.Base.++_info _cn5t: movq $24,904(%r13) _cn5q: jmp *-16(%r13) Except this difference the rest of the assembly looks pretty similar in both the cases. The corresponding dump-simpl output for the pure case: False -> ++ @ Char (GHC.Types.: @ Char ww_amuh (GHC.Types.[] @ Char)) (Data.Unicode.Internal.Normalization.decompose_$sdecompose ipv_smuv ipv1_smuD); And for the IO monad version: False -> case $sa1_sn0g ipv_smUT ipv1_smV6 ipv2_imWU of _ [Occ=Dead] { (# ipv4_XmXv, ipv5_XmXx #) -> (# ipv4_XmXv, ++ @ Char (GHC.Types.: @ Char sc_sn0b (GHC.Types.[] @ Char)) ipv5_XmXx #) }; The dump-simpl output is essentially the same except the difference due to the realworld token in the IO case. Why is the generated code different? I will appreciate if someone can throw some light on the reason or can point to the relevant ghc source to look at where this happens. I am using ghc-7.10.3 in native code generation mode (no llvm). Thanks, Harendra

5 11

Magic classes for Overloaded Record Fields, overlaps, FunDeps
by AntC 16 May '16

16 May '16

There's an intriguing comment here wrt anonymous records: https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/ MagicClasses#Designextension:anonymousrecords (End of the section) "... this doesn't quite work, because the two instances overlap, but it is possible with a bit more trickery" I could well understand if everybody's forgotten what was the "trickery", because ORF has been so long in the pipeline, but could anyone explain? Reason for the q: I'm looking at anonymous records myself, including extending, shortening and joining anon records. And yes overlapping instances are everywhere. Using type families isn't being too ergonomic. And I notice ORF has used FunDeps. But for me, FunDeps in the HList style is also rather ugly. Is there some trickery I'm missing? Thanks AntC

3 6

Looking for GHC compile-time performance tests
by Ben Gamari 07 May '16

07 May '16

tl;dr. Do you have a Haskell project which GHC now compiles more slowly than in the past? If you would like to see your program's compilation time improve in 8.2, reduce it to a minimal testcase, and provide it to us via Trac. Good news everyone, GHC 8.2 will be a release largely targetting consolidation instead of new features. In particular, we will focus on compiler performance issues. One of the challenges of this task is knowing in which ways GHC has regressed. It is currently hard to know how much of the apparent compiler performance regression is due to GHC getting slower and how much is due to users demanding more of it. To better understand the performance of our compiler, we would like to collect modern Haskell code samples that exhibit compile-time performance issues (either regressions or otherwise). For this we are asking for your help: we are looking for projects that, * are small-to-moderate-sized Haskell programs which you believe have regressed in compile time in the last few GHC releases * have minimal build dependencies, in the ideal case none outside of the standard GHC boot libraries * can be licensed for use under 3-clause BSD In some cases we may also be able to make use of examples with a few library dependencies that are necessary to demonstrate the performance issue (for instance, a suspected issue stemming from stream fusion requiring Conduit). For performance issues exhibiting non-linear scaling in some quantity (e.g. the size of a type in the program), it would be extremely helpful if the testcase exposed a "knob" demonstrating this scaling. So, if you would like to see your program's compilation time improve in GHC 8.2, put some time into reducing it to something minimal, submit it to us via a Trac ticket, and let us know in this thread. Thanks for your help! Cheers, - Ben

7 7

RFC: Removing the `-hb` profiling option
by Erik de Castro Lopo 06 May '16

06 May '16

Hi all, After a bit of rather tedious and frustrating debugging I came to the realisation that the code for the `-hb` profiling option is not thread safe. See https://ghc.haskell.org/trac/ghc/ticket/12019 This gives us an opportunity to simply remove it instead of fixing it. If there is anyone that thinks this future is really useful (ie more useful than the other profiling modes) then I'm willing to fix it. But if noone would miss it. I'd much rather remove it. Thoughts? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

6 5

Re: [Maintainer needed] Actively maintained Haddock are happy Haddock
by Ben Gamari 06 May '16

06 May '16

Sebastian <arnaudpourseb(a)gmail.com> writes: > Hello Ben, > Hi Sebastian, Sorry for the belated response. > If that's ok I'd be happy to take over the maintenance of Haddock. > Sure, that would be great. I can give you the keys in a bit. Cheers, - Ben

1 0

What happened to -optdep option?
by Volker Wysk 06 May '16

06 May '16

Hello! I'm using GHC 7.10.3 after an upgrade. I have the following in my Makefile: depend_mod :: lib/abh ghc -M $(CFLAGS_GHC_0) -dep-makefile -optdepbuild/depend.tmp -dep-suffix "p_" \ $(foreach m, $(MOD_HS) $(PROG_HS), src/$(m).hs) \ $(foreach m, $(MOD_CHS) $(PROG_CHS), build/$(m).hs) ... This used to work. The previous GHC version was 7.8. Now GHC complains: -optdepbuild/depend.tmp: openBinaryFile: does not exist (No such file or directory) This looks like the -optdep argument isn't understood. There is no mention of it in the new/7.10.3 user manual. I don't know any longer what this "-optget" argument does, and it isn't in the documentation any longer. I googled the GHC web site. There it is mentioned that -optdep was deprecated, but almost all of the hits are very outdated (like ten years old). Can soneone tell me, how I should change my Makefile..? Greetings, Volker Wysk

2 2

[Maintainer needed] Actively maintained Haddock are happy Haddock
by Ben Gamari 04 May '16

04 May '16

tl;dr. Our Haddock need a dedicated maintainer responsible for their care and feeding. Would you like to move forward a critical piece of infrastructure used on a daily basis by thousands of Haskellers? Let us know if so. Hello everyone, While for several years Mateusz Kowalczyk and Simon Hengel have done an admirable job in serving as comaintainers of the Haddock documentation tool, they have both indicated that they no longer have the time to continue to be active in this role. They both deserve our thanks for their service. While Matthew Pickering and I have tried to pick up some of the Haddock's maintenance load in the meantime, we really need a dedicated maintainer to ensure that Haddock continues to swim along healthfully. At the moment there are over 150 open tickets in the issue tracker [1], an open call for a stable release, and 4 patches in need of review. We currently lack the time to get on top of such a load. In particular, Haddock need someone to take ownership of the management of the project: this person would keep an eye on (and preferably pare down) the issue tracker (which typically isn't very active, happily), guide new contributors, and manage releases. This is an opportunity to drive forward a project used on a daily basis by a significant fraction of Haskellers. If you think you might be interested in serving in this role, please let us know. Thanks! Cheers, - Ben [1] https://github.com/haskell/haddock/pulls

1 0

[ANNOUNCE] GHC 8.0.1 release candidate 4 available
by Ben Gamari 29 Apr '16

29 Apr '16

Hello Haskellers, The GHC team is happy to announce the availability of fourth release candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and binary distributions can be found at, http://downloads.haskell.org/~ghc/8.0.1-rc4/ This is the last of four candidates leading up to the 8.0.1 release, addressing nearly all of the known issues of the previous candidates. These include, * A type-checker panic triggered by use of Typeable on a kind-polymorphic type constructor (#11334) * A type-checker explosion where -XTypeInType would gobble up massive amounts of memory when used in a data instance (#11407) * A variety of other typechecker issues (#11811, #11797, #11813, #11814) * A build issue seen on OS X (#11828) * Template Haskell can now produce instances with OVERLAPP{ING,ABLE,ED} pragmas * Autoconf has improved version checks for libdw (#11820) * Typeable and hs-boot files now interact nicely (#11824) * The build system now checks for the broken Apple `nm` utility (#11823, #11744) * Various issues involving unexpected laziness resulting in exception handlers not being invoked (#11555) * GHC now fails more gracefully when used with an older cabal-install release (#11558) * TypeInType now has proper documentation in the users guide (#11614) * The story surrounding type `RuntimeRep`s (formerly known as `Levity`) is now far better developed, closing several doors to unsafe behavior that TypeInType previously opened (#11473, #11723) * A long-standing bug in the constant-folding rules for `mod` for the `Word` type has been resolved (#11702) * Various issues introduced by OverloadedRecordFields have been fixed (#11662, #11401) * A regression in the typechecker resulting in the rejection of code in the `free` and `microlens` packages has been fixed (#11608) * A bug in the LLVM code generator which caused some programs to emit unbuildable LLVM IR has been fixed (#11649) * A bug where pattern synonyms defined in terms of a pattern match on a record would be rejected if the fields weren't written in the same order as they were defined has been resolved (#11633) * A bug in the runtime system's treatment of weak references which could result in segmentation faults in some cases has been fixed (#11108) * a variety of optimizations improving compiler performance have been merged * and many others Mac OS X users should be aware that the recent XCode 7.3 release ships with a broken `nm` utility which breaks the GHC build (#11744, #11823). The build system will check for this condition and request that the tree is configured to use the `nm-classic` utility if found. OS X users running XCode 7.3 are encouraged to open a ticket with Apple so that this issue may be fixed in future XCode releases. If no major issues pop up we expect that this will be the last release candidate before the final release, which we hope to push out in the coming weeks. Thanks to everyone who has contributed code, testing, builds, and bug reports thusfar! Cheers and happy testing, - Ben

3 2

[ANNOUNCE] GHC 8.0.1 release candidate 3 available
by Ben Gamari 23 Apr '16

23 Apr '16

Hello Haskellers, The GHC team is happy to announce the availability of third release candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and binary distributions can be found at, http://downloads.haskell.org/~ghc/8.0.1-rc3/ This is the third of what will be four candidates leading up to the 8.0.1 release. As there are a number of known issues with this candidate, we expect to produce the fourth and final release candidate shortly. While we considered not releasing this candidate at all and instead skipping to rc4, we decided that it would be helpful to make it available despite its issues to increase the likelihood of catching any remaining bugs. That being said, this candidate lacks the range of binary distributions which we usually offer, * We are unable to release Windows bindists due to a compatibility issue which we didn't catch until after preparing the source distribution. * Binaries targeting Redhat distributions are currently not available Regardless, users for whom a distribution is available are encouraged to try this candidate as it fixes dozens of issues present in release candidate two. These include, * A type-checker panic triggered by use of Typeable on a kind-polymorphic type constructor (#11334) * A type-checker explosion where -XTypeInType would gobble up massive amounts of memory when used in a data instance (#11407) * Various issues involving unexpected laziness resulting in exception handlers not being invoked (#11555) * GHC now fails more gracefully when used with an older cabal-install release (#11558) * TypeInType now has proper documentation in the users guide (#11614) * The story surrounding type `RuntimeRep`s (formerly known as `Levity`) is now far better developed, closing several doors to unsafe behavior that TypeInType previously opened (#11473, #11723) * A long-standing bug in the constant-folding rules for `mod` for the `Word` type has been resolved (#11702) * Various issues introduced by OverloadedRecordFields have been fixed (#11662, #11401) * A regression in the typechecker resulting in the rejection of code in the `free` and `microlens` packages has been fixed (#11608) * A bug in the LLVM code generator which caused some programs to emit unbuildable LLVM IR has been fixed (#11649) * A bug where pattern synonyms defined in terms of a pattern match on a record would be rejected if the fields weren't written in the same order as they were defined has been resolved (#11633) * A bug in the runtime system's treatment of weak references which could result in segmentation faults in some cases has been fixed (#11108) * a variety of optimizations improving compiler performance have been merged * and many others Mac OS X users should be aware that the recent XCode 7.3 release ships with a broken `nm` utility which breaks the GHC build (#11744, #11823). Unfortunately, this candidate does not notice this brokenness and odd behavior can result. OS X users running XCode 7.3 are encouraged to open a ticket with Apple and build GHC with the `--with-nm=nm-classic` configure option until a fix is available. As mentioned earlier, there are a number of known issues with this candidate which will be addressed in release candidate four. These issues include, * A number of typechecker bugs (#11811, #11797, #11813, #11814) * A build issue seen on OS X (#11828) * Template Haskell lacks the ability to produce instances with OVERLAPP{ING,ABLE,ED} pragmas * Autoconf has inadequate version checks for libdw (#11820) * Typeable and hs-boot files interact poorly (#11824) * The build system doesn't check for the broken Apple `nm` utility, leading to unpredictable results (#11823, #11744) We hope to have release candidate four available by the middle of next week. Thanks to everyone who has contributed code, testing, builds, and bug reports thusfar! Cheers, - Ben

2 1