March 2016 - ghc-devs

Improving trac notifications
by Matthew Pickering 13 Feb '17

13 Feb '17

I subscribe to the ghc-tickets[1] mailing list which provides updates to all trac tickets. This is very useful, however when a ticket description is updated the whole description is included in the email which makes it hard to see what actually changed. The web interface shows a nice diff[2] of the changes, I think it would be good if emails could also include a diff rather than the current quite useless output. After a bit of investigation, it appears that the easiest way to achieve this is apply a simple patch to our copy of trac. The current format is hard coded on line 558 in this module, it seems easy to modify this section to instead provide a diff. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.ticket.notification-pys… There is also already a module which has the diff operations implemented which could be used. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.versioncontrol.diff-mod… Another option would be to use something like the `AnnouncerPlugin`[3] but that seems like much more work and would still require someone to write a custom formatter. Any thoughts? Matt [1]: https://mail.haskell.org/mailman/listinfo/ghc-tickets [2]: https://ghc.haskell.org/trac/ghc/ticket/10873?action=diff&version=6 [3]: https://trac-hacks.org/wiki/AnnouncerPlugin

3 8

RE: vectorisation code?
by Simon Peyton Jones 13 Sep '16

13 Sep '16

Austin, (or anyone else) Manuel says: | > Would it be ok if we left it in the repo, but CPP'd it out so that | we | > didn't compile everything? (The DPH library is in the same state at | > the moment.) | > | > It might suffer bit-rot, but it’d still be there for resurrection. | | Sure, that’s ok. Could you action this? Just avoid compiling anything in 'vectorise/', using (I suppose) cpp to create a stub where necessary. Leave enough comments to explain! Simon | | I hope everything is fine in Cambridge! | Manuel | | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | > | Manuel M T Chakravarty | > | Sent: 16 January 2015 02:58 | > | To: Richard Eisenberg | > | Cc: ghc-devs(a)haskell.org Devs | > | Subject: Re: vectorisation code? | > | | > | [Sorry, sent from the wrong account at first.] | > | | > | We currently don’t have the resources to work on DPH. I would | > | obviously prefer to leave the code in, in the hope that we will be | > | able to return to it. | > | | > | Manuel | > | | > | > Richard Eisenberg <eir(a)cis.upenn.edu>: | > | > | > | > Hi devs, | > | > | > | > There's a sizable number of modules in the `vectorise` | > | subdirectory of GHC. I'm sure these do all sorts of wonderful | > | things. But what, exactly? And, does anyone make use of these | wonderful things? | > | > | > | > A quick poking through the code shows a tiny link between the | > | vectorise code and the rest of GHC -- the function `vectorise` | > | exported from the module `Vectorise`, which is named in exactly | one | > | place from SimplCore. From what I can tell, the function will be | > | called only when `-fvectorise` is specified, and then it seems to | > | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE | > | #-}` doesn't appear in the manual at all, and `-fvectorise` is | > | given only a cursory explanation. It seems these work with DPH... | > | which has been disabled, no? Searching online finds several hits, | > | but nothing more recent than 2012. | > | > | > | > I hope this question doesn't offend -- it seems that | > | vectorisation probably has amazing performance gains. Yet, the | > | feature also seems unloved. In the meantime, compiling (and | > | recompiling, and | > | recompiling...) the modules takes time, as does going through | them | > | to propagate changes from elsewhere. If this feature is truly | > | orphaned, unloved, and unused at the moment, is it reasonable to | > | consider putting it on furlough? | > | > | > | > Thanks, | > | > Richard | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs(a)haskell.org | > | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs

13 35

7.10.3 fails to build with Xcode 7.3
by Manuel M T Chakravarty 14 Apr '16

14 Apr '16

I just noticed that GHC 7.10.3 (latest release version) fails to build with version 7.3 of Xcode (which just came out of beta). Maybe this is due to https://ghc.haskell.org/trac/ghc/ticket/11744 The problem manifests in the form of a SEGV when dll-split is invoked for the first time — specifically lldb has the following to say, Process 17348 launched: '../lib/bin/dll-split' (x86_64) Process 17348 stopped * thread #1: tid = 0x4a821e, 0x0000000100e26357 libHSrts-ghc7.10.3.dylib`stg_returnToStackTop + 7, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1e) frame #0: 0x0000000100e26357 libHSrts-ghc7.10.3.dylib`stg_returnToStackTop + 7 libHSrts-ghc7.10.3.dylib`stg_returnToStackTop: -> 0x100e26357 <+7>: movq 0x1e(%rax), %rbx 0x100e2635b <+11>: movq 0x10(%rbx), %rbp 0x100e2635f <+15>: leaq 0x126(%rbx), %r15 0x100e26366 <+22>: movq $0x0, 0x904(%r13) Interestingly, the GHC 8.0.1-rc2 build does not exhibit that same failure. It does, however, fail to build due to an undefined symbol: Undefined symbols for architecture x86_64: "_stg_sel_18_upd_info", referenced from: _sc9J_info in Monad.dyn_o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1) make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1 make: *** [all] Error 2 (This may be unrelated to Xcode 7.3 and a known problem on OS X with that RC. I didn’t follow the 8.0.1-rc2 tickets in detail.) As I assume that there will be no further 7.10 release, I am posting this here just to save others the time to track the problem down. Manuel PS: I wish I had the time to check GHC builds with Xcode beta releases, but alas, I usually don’t.

3 4

Initial compile time benchmarks
by Ömer Sinan Ağacan 01 Apr '16

01 Apr '16

Hi all, Using Ben's timing patch [^1], Cabal, and a Haskell program to parse generated logs [^2], I generated some tables that show compile times of modules in hxt, haskell-src-exts, lens, and all of their dependencies: https://gist.githubusercontent.com/osa1/fd82335181a584679c9f3200b7b0a8a5/ra… Some notes: - Modules and passes in modules are sorted. - At the end of the file you can see the cumulative numbers for the passes. In fact, that's a small table so I'm just going to paste it here: ======================Total====================== CodeGen 41.32% Simplifier 34.83% Renamer/typechecker 12.22% Desugar 2.11% CorePrep 1.90% Demand analysis 1.44% CoreTidy 1.35% Called arity analysis 1.10% Float inwards 0.96% Common sub-expression 0.87% Parser 0.75% SpecConstr 0.57% Specialise 0.30% Worker Wrapper binds 0.17% Liberate case 0.12% ByteCodeGen 0.00% Simplify 0.00% I don't know how to make use of this yet, but I thought ghc-devs may find it useful. As a next thing I'm hoping to add some more `withTiming` calls. The analyze program can handle nested `withTiming` calls and renders passes as a tree (GHC HEAD doesn't have nested `withTiming`s so we don't see it in the file above), so we can benchmark things in more details. I also want to experiment a little bit with different `force` parameters to `withTiming`. If anyone has any other ideas I can also try those. --- [^1]: https://phabricator.haskell.org/D1959 [^2]: https://github.com/osa1/analyze-ghc-timings

7 10

Perf
by Simon Peyton Jones 01 Apr '16

01 Apr '16

Joachim Harbormaster seems to be saying that GHC’s perf got a lot worse https://phabricator.haskell.org/harbormaster/ after Buildable 9015, which omitted the oneshot info. The typechecker seems to allocate a lot more. That is not good. Revert and investigate? Simon

2 2

RE: [commit: ghc] master: Refactor in TcMatches (bdd9042)
by Simon Peyton Jones 31 Mar '16

31 Mar '16

Ben, Austin The group of around six refactoring patches I have just committed are inessential for 8.0, but I think they are solid enough to merge if some other later patch depends on them. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 31 March 2016 08:02 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Refactor in TcMatches (bdd9042) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.has | kell.org%2ftrac%2fghc%2fchangeset%2fbdd90426a7f88d57bedf15411fa00f62aeb | 22172%2fghc&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c23c66899d | 70e4e74cd8608d35932b916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Lw | 9ByEHKPpKZb%2fsgZQc1dpCjTm8yNAh5%2b1izy9PdgX0%3d | | >--------------------------------------------------------------- | | commit bdd90426a7f88d57bedf15411fa00f62aeb22172 | Author: Simon Peyton Jones <simonpj(a)microsoft.com> | Date: Wed Mar 30 17:14:11 2016 +0100 | | Refactor in TcMatches | | * Move the several calls of tauifyMultipleMatches into tcMatches, | so that it can be called only once, and the invariants are | clearer | | * I discovered in doing this that HsLamCase had a redundant and | tiresome argument, so I removed it. That in turn allowed some | modest but nice code simplification | | | >--------------------------------------------------------------- | | bdd90426a7f88d57bedf15411fa00f62aeb22172 | compiler/deSugar/Coverage.hs | 2 +- | compiler/deSugar/DsExpr.hs | 7 +++---- | compiler/deSugar/DsMeta.hs | 2 +- | compiler/hsSyn/Convert.hs | 3 +-- | compiler/hsSyn/HsExpr.hs | 16 +++++++++------- | compiler/parser/Parser.y | 2 +- | compiler/rename/RnExpr.hs | 5 ++--- | compiler/typecheck/TcExpr.hs | 17 +++++++++-------- | compiler/typecheck/TcHsSyn.hs | 7 +++---- | compiler/typecheck/TcMatches.hs | 24 ++++++++---------------- | compiler/typecheck/TcRnTypes.hs | 2 +- | 11 files changed, 39 insertions(+), 48 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | bdd90426a7f88d57bedf15411fa00f62aeb22172 | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha | skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c23c66899d70e4 | e74cd8608d35932b916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8kgpTH | G1JUjyHegki%2bBXMZ6gdSlUReHDY5pQIdaUqMg%3d

1 0

nix build haskell.compiler.ghcHEAD
by Rahul Muttineni 31 Mar '16

31 Mar '16

Hi GHC Devs, Refer https://github.com/NixOS/nixpkgs/issues/14333 for a problem I was having when building with nix. The interesting part is that if I add an extra flag -optl-lpthread manually, the error goes away and the build succeeds. My question is why the build system didn't add the -optl-lpthread flag when libpthread was a requirement for that particular build? Thanks, Rahul Muttineni

1 1

Unicode, strings, and Show
by Manuel M T Chakravarty 31 Mar '16

31 Mar '16

Why are we doing this? GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> "文字" "\25991\23383" Prelude> After all, we don’t print ’a’ as ’\97’. Manuel

7 12

GHC HEAD compile failure at ghctags: "missing: Cabal >=1.25 && <1.27"
by Conal Elliott 31 Mar '16

31 Mar '16

I'm trying to recompile GHC (via GHC 7.10.3) from freshly git-pulled HEAD, and "make" keeps dying at ghctags: Configuring ghctags-0.1... ghc-cabal: At least the following dependencies are missing: Cabal >=1.25 && <1.27 According to ghc-pkg I have Cabal 1.25.0.0 (compiled from a freshly git-pulled git clone). Any ideas what's going on and how I can fix it? Thanks. - Conal

2 2

singletons stuff in GHC.Generics?
by Carter Schonwald 31 Mar '16

31 Mar '16

Hey All, i just noticed that theres some Singletons code in the GHC.Generics module thats defined but not exported, whats the context on that? https://ghc.haskell.org/trac/ghc/ticket/11775#ticket is the ticket i created to track / ask for clarificaiton:) _Carter

2 2