- ghc-devs - Haskell.org

Removing -fext-core
by Austin Seipp 30 Apr '14

30 Apr '14

Hello all, Recently I was wondering something: is there any reason to keep -fext-core around? In particular, it's been broken for a while at this point, see GHC bug #5630[1] As far as I'm aware there really aren't any users of it still around these days, at least none working with a modern GHC. And it seems like if people were to need access to Core, they could use a plugin or some such to get direct access to what they want. Simon mentioned removing ExtCore in face of replacing it with IfaceSyn in the compiler. I'm not entirely sure how much work that would be to bring it all up to scratch if people needed it, but maybe it's worth thinking about. One other issue is a notion of semantics which is present in External Core, but we also now have a documented semantics for GHC's core language as well (which has evolved quite a bit), so I don't know how much that matters. So long story short: I don't think anyone is using it, maintaining it, and it seems subsumed by more recent events. Therefore, if nobody objects, I'd vote to remove -fext-core from GHC, unless someone is willing to step up and really maintain it. If you're using it, you should probably speak up soon I'd imagine... [1] https://ghc.haskell.org/trac/ghc/ticket/5630 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 4

RE: [commit: ghc] master: Improve implementation of unSubCo_maybe. (a3896ab)
by Simon Peyton Jones 29 Apr '14

29 Apr '14

Richard, Looks good, but *surely* worth a Note [unSubCo] in the file? It's manifestly non-obvious or you'd have done this from day 1. Moreover, the *reason* Conal needed it, and the new optimsations it enables, are also non-obvious and deserve examples! Evernyone: my obsession with Notes is born of the hours I have spent staring at code that has cases I don't understand; or "fixing" something turned out to be there for a good but undocumented reason. Going back to unSubCo, I think the start of the documentation could be if g :: t1 ~R t2 then unSubCo g :: t ~N t2 (if it succeeds at all). But why do we need it? And what optimisations do we get? Thanks Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 29 April 2014 00:51 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Improve implementation of unSubCo_maybe. | (a3896ab) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/a3896ab5d2dc88160f710705bf23e6 | e25e327da5/ghc | | >--------------------------------------------------------------- | | commit a3896ab5d2dc88160f710705bf23e6e25e327da5 | Author: Richard Eisenberg <eir(a)cis.upenn.edu> | Date: Mon Apr 28 13:33:13 2014 -0400 | | Improve implementation of unSubCo_maybe. | | This is the result of an email conversation (off list) with | Conal Elliott, who needed a stronger unSubCo_maybe. This | commit adds cases to upgrade the role of a coercion when | recursion is necessary to do say (for example, for a use of | TransCo). As a side effect, more coercion optimizations are | now possible. | | This was not done previously because unSubCo_maybe was used | only during coercion optimization, and the recursive cases | looked to be unlikely. However, adding them can cause no harm. | | unSubCo_maybe is now also exported from Coercion, for use | cases like Conal's. | | | >--------------------------------------------------------------- | | a3896ab5d2dc88160f710705bf23e6e25e327da5 | compiler/types/Coercion.lhs | 20 +++++++++++++++----- | 1 file changed, 15 insertions(+), 5 deletions(-) | | diff --git a/compiler/types/Coercion.lhs b/compiler/types/Coercion.lhs | index af2b2fa..f60fcbd 100644 | --- a/compiler/types/Coercion.lhs | +++ b/compiler/types/Coercion.lhs | @@ -38,7 +38,7 @@ module Coercion ( | splitAppCo_maybe, | splitForAllCo_maybe, | nthRole, tyConRolesX, | - nextRole, | + nextRole, unSubCo_maybe, | | -- ** Coercion variables | mkCoVar, isCoVar, isCoVarType, coVarName, setCoVarName, | setCoVarUnique, @@ -1051,16 +1051,26 @@ maybeSubCo2 r1 r2 co | | -- if co is Nominal, returns it; otherwise, unwraps a SubCo; otherwise, | fails unSubCo_maybe :: Coercion -> Maybe Coercion | +unSubCo_maybe co | + | Nominal <- coercionRole co = Just co | unSubCo_maybe (SubCo co) = Just co | unSubCo_maybe (Refl _ ty) = Just $ Refl Nominal ty -unSubCo_maybe | (TyConAppCo Representational tc cos) | - = do { cos' <- mapM unSubCo_maybe cos | +unSubCo_maybe (TyConAppCo Representational tc coes) | + = do { cos' <- mapM unSubCo_maybe coes | ; return $ TyConAppCo Nominal tc cos' } unSubCo_maybe (UnivCo | Representational ty1 ty2) = Just $ UnivCo Nominal ty1 ty2 | -- We do *not* promote UnivCo Phantom, as that's unsafe. | -- UnivCo Nominal is no more unsafe than UnivCo Representational - | unSubCo_maybe co | - | Nominal <- coercionRole co = Just co | +unSubCo_maybe (TransCo co1 co2) | + = TransCo <$> unSubCo_maybe co1 <*> unSubCo_maybe co2 unSubCo_maybe | +(AppCo co1 co2) | + = AppCo <$> unSubCo_maybe co1 <*> pure co2 unSubCo_maybe (ForAllCo tv | +co) | + = ForAllCo tv <$> unSubCo_maybe co | +unSubCo_maybe (NthCo n co) | + = NthCo n <$> unSubCo_maybe co | +unSubCo_maybe (InstCo co ty) | + = InstCo <$> unSubCo_maybe co <*> pure ty | unSubCo_maybe _ = Nothing | | -- takes any coercion and turns it into a Phantom coercion | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

3 4

optllvm failures
by Daniel Fischer 29 Apr '14

29 Apr '14

I have done a bit of testing with regards to my optllvm failures in the testsuite. Some tests compile but segfault when they are run, others fail to compile, both with HEAD and 7.8.2, but those I tested all work with 7.6.3, although 7.6 gives the warning: You are using a new version of LLVM that hasn't been tested yet! We will try though... I suspect that the LLVM backend thinks I have a different version than I actually have, or maybe the LLVM tools think I have a different CPU than I have: dafis@schwartz:~/JNthPrime> llc --version LLVM (http://llvm.org/) LLVM version 3.2svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx Registered Targets: arm - ARM ppc32 - PowerPC 32 ppc64 - PowerPC 64 thumb - Thumb x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 dafis@schwartz:~/JNthPrime> opt --version LLVM (http://llvm.org/) LLVM version 3.2svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx But my CPU is a Core i5, not i7. Can somebody confirm or deny that that may be the cause?

4 7

GHC builder: out of memory from ghc during make
by Alain O'Dea 29 Apr '14

29 Apr '14

I am trying to get GHC builder-clients running for x86 and x86_64 GHC on SmartOS. I have been trying to get to the bottom of this memory issue and have had no luck. I've set it aside for the past couple of days to try to get a clear head to attack it afresh tonight. The three latest builds die with the following message: ghc: out of memory (requested 2097152 bytes) compiler/ghc.mk:641: recipe for target 'compiler/stage1/build/DynFlags.o' failed http://haskell.inf.elte.hu/builders/smartos-x86_64-head/16/10.html http://haskell.inf.elte.hu/builders/smartos-x86_64-head/17/10.html http://haskell.inf.elte.hu/builders/smartos-x86_64-head/18/10.html All of these were run interactively from the builder directory: builder-client --do-build Here's my zone setup: image: SmartOS base64 13.4.2 max_physical_memory: 4GB max_swap: 8GB disk_quota: 200GB # ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited open files (-n) 65536 pipe size (512 bytes, -p) 10 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 12261 virtual memory (kbytes, -v) unlimited It doesn't use anywhere near the 4GB of memory or 8GB of swap allocated to the zone. Total zone RSS (physical memory usage) stays under 200MB for the entire builder-client run. I took regular snaps of memory during the build run and saw no evidence of memory saturation or errors. It's nowhere near hitting swap limits either. I think I've done all I can do to remove system imposed resource limits. This doesn't happen when I run make directly from a shell myself. It looks like a defect in the GHC builder-client itself. If POSIX resources are available on the host (which they are on SmartOS) builder-client sets a 1GB ResourceTotalMemory limit using System.Posix.Resource.setResourceLimit: https://github.com/haskell/ghc-builder/blob/master/client/client.hs#L54 I'm trying a build with the resource limit code commented out. Hopefully that will finally put this to bed. Speaking of bed, I should probably sleep too. If anyone has any other ideas I'd be very happy for the help. Best, Alain

2 1

[Urgent] Please fill out the 2014 HCAR entry for GHC!
by Austin Seipp 28 Apr '14

28 Apr '14

Hello all, I hate to pester so late, but this completely slipped my mind *twice* so I'm afraid I have to! The HCAR entry deadling is rapidly approaching (~May 1st), and before I send off what we have to Mihai, I'd like everyone to pitch in as much as possible. I've already gone ahead and filled out the skeleton. Now I need y'all to fill in details. To that end, I've directly CC'd interested parties, and replicating the message here - if your name is below, please take a quick look over, it shouldn't take you long. * Richard - I copied over the note about the old Explicit Type Application work - do you have any update on what its current status is? I also was under the impression the new kind equalities work *may* go into 7.10, but I haven't heard anything yet. Do please confirm and edit as you see fit. * Iavor - I know you, Eric, and Trevor had worked on Kinds without Data before. Do you know of its current status? I copied the current notes into the page - I also believe you have some recent work involving using an SMT solver in the type-checker, which is quite interesting! If you feel like it, please do mention it, I'm sure people would like to hear. * Thomas - everyone is excited about PartialTypeSignatures I think. Please edit the page and write what you'd like - there's a tiny stub there already. * Edward, Simon, Johan - I'm not sure what you're working on, but I imagine you may have some runtime system or optimization changes up your sleeve. Do feel free to add in things you feel you should mention. * SimonM - I've added a small note for ApplicativeDo. Please feel free to expand or tweak it as you see fit. * Herbert - Do please make the new repository changes clear, and be sure to mention anything else you might be working on (perhaps more integer-gmp improvements?) Please spread the word (by mouth somehow or IRC) - I'll be monitoring the page closely for the next few days and send it to Mihail once it's been expanded upon. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 3

Status updates
by Austin Seipp 28 Apr '14

28 Apr '14

Hello all, Here's what's gone on this week: - The HCAR is happening! I sent an email about this earlier, but PLEASE, if you're working on something, add it to the page for the May 2014 report! I won't forget the link this time: https://ghc.haskell.org/trac/ghc/wiki/Status/May14 - ORF is still waiting for a merge. I believe Simon was looking over it this past week - I'm sure we'll talk about it later today. - AMP is still waiting for merge, I think we'll have to coordinate a Happy release as well to match (the fix I have is slightly unsatisfactory). I'll talk to Simon about this today. - My extended-rep-movsb patch is on wip/ermsb, but it needs to be benchmarked and tested before I merge it. Unordered-containers will be my baseline, since Johan tells me it's sensitive to copies like this (it may also need alignment tweaking, on this note). - Many of the Coverity bugs have been fixed, hooray! We will probably fix some more of them - all of the current fixes have gone into 7.8 as well. - I triaged the bug tracker a lot this morning as I'm sure you can all see. I went through a bunch of them, closed tickets, punted, lowered priority, etc. - I've proposed to remove External Core - if you need it, you should speak up *soon*, otherwise I will probably nuke it sometime this week: http://www.haskell.org/pipermail/ghc-devs/2014-April/004791.html The work to do this is on wip/kill-extcore, so again, speak soon or forever hold your peace. - The 7.8.3 milestone has been shaped up. Please take a look at the outstanding tickets: https://ghc.haskell.org/trac/ghc/milestone/7.8.3 https://ghc.haskell.org/trac/ghc/query?status=infoneeded&status=merge&statu… Note that *not* all of these will be fixed - but these are the ones we will pay attention to for the 7.8.3 release. So do have a look over and if you think you can fix something, please do so! ------------- Some things I've been thinking about: - One really annoying thing about the way we generate source-distributions is that we must do a build first, but this practically negates the need for a sdist! Joachim in particular finds this annoying too for the Debian builds. Ideally we could build a source dist immediately from the repository, and then build from that. This has the benefit the CI system is always testing something that a user can build and make themselves. The problem here is that we need to run Happy and Alex on the parser, which is part of the stage1/stage2 build. Although it's kind of a hack, I think we can do this differently, but I haven't tried it. In particular, they do not depend on any CPP, so we could just immediately generate them up front in the build process. This is kind of a gross hack from the build-system's point of view, but it would make this task much easier. - For right now, I'd like to go with Stackage for building a subset of packages against HEAD I think. Herbert recently uploaded fresh PPAs for GHC HEAD recently, so I think we can already begin the process of testing things and seeing how/why they break. Of course, not everyone will always need to pay attention to this, and sometimes it *will* be broken (c.f. upcoming AMP changes). But in the long run I think this will be very useful, and we can also set it up for the 7.8 branch. I'll be spinning up some new machines today and reply with some updates on this later. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Strange checkout message
by Simon Peyton Jones 28 Apr '14

28 Apr '14

Herbert or others, What does this mean (in a clean tree) git checkout wip/orf Checking out files: 100% (159/159), done. M utils/haddock Branch wip/orf set up to track remote branch wip/orf from origin. Switched to a new branch 'wip/orf' simonpj@cam-05-unx:~/code/HEAD-3$ What's all this about haddock being modified? I've just checked out a branch, which is supposed to make everything line up, isn't it? Do you need to say "git submodule update" as well? Could this be documented in the (upcoming?) workflows page? Thanks Simon

3 2

Status updates
by Austin Seipp 27 Apr '14

27 Apr '14

Hello all, At the behast of Simon&Simon, we're going to start doing weekly summary updates. We generally meet every week, but lots of times people may not be privvy to our plans. Here's to fixing that! (I would have started last week actually - but I got cut off by a hardware failure last week due to a lightning storm that fried some stuff! Nothing ultra critical, and after a little time and some replacements, though, everything seems OK.) So here's a status summary of what I've been up to, and what the plans are: - Last week, I was cut short on time due to hardware failure, but I spent time this past weekend playing catch-up a bit. - The new OverloadedRecordFields extension is Ready To Go, as I hinted on the list earlier. You can find the work on 'wip/orf' branches in GHC and Haddock. Thanks to Adam, catching this back up to HEAD did not take very long. I would like to merge it within the next week before it bitrots any further. If you're working on a branch dealing with the renamer, name resolution, desugaring, be warned! Big patch incoming! - The Applicative/Monad changes are on their way. After some minor fiddling this morning, the patches are about 95% complete I'd say - they just require a few minor touchups to some upstream libraries. I'd like to merge the AMP patches within the week if possible. They're pending review from the Core Libraries committee now. This patch should not negatively impact anyone working on base right now, I imagine. Or at least not very much. - I spent some time on a new optimization for low-level memory copies, and support for -march/-mcpu in GHC as a side project, so we can take advantage of CPU-specific features more easily. After some fumbling on Saturday and wanting to merge them, I got stalled by a problem, but I think I see my (horrific, stupid, stupid) error now upon review. Hopefully I can get this in soon. - I also spent time this week trying something else fun: I spent a few hours dealing with the Coverity static analyzer tool, attempting to run it over the GHC Runtime system. I succeeded! According to their statistics, it has a total of 124,074 LOC analyzed (this includes header files), with 44 detected possible defects throughout, with a defect ratio of 0.35. If their claims are to be believed, they typically hit within a 5-20% false positive rate. That would mean 30 of these bugs could be real, in fact. At the moment, Scan results are not public, and I do not (yet) have access to the defects. If you'd like access, don't worry - I'll be sending out another email soon about this, and who wants access to the reports... If you'd like to know more, see https://scan.coverity.com - I made some merges to the GHC branch, and all outstanding merges are now done, minus one from Carter, which I will take care of soon (I made it fall out of date, totally my fault). So far, the 7.8.3 branch contains about 7 bug fixes, but more are surely going to be on the way. - There's a new 7.8 FAQ page - https://ghc.haskell.org/trac/ghc/wiki/GHC-7.8-FAQ - over the past few weeks, I've spent time talking to users and collecting some pitfalls they've run into, since a lot of things changed this cycle. This page is preliminary, but *many* people have been tripped up by the few things in there! If you've encountered some stumbling block with 7.8, please add it to the page. Also, if the wording is confusing, please re-word it if you can, or tell me! I will advertise this FAQ more widely to glasgow-haskell-users soon. ------------------------------------------------------------------------------------------ But what about this week? Well: - Like I said above, I'll be merging some things, hopefully including: my optimization, ORF, and the AMP changes. Watch this space. - I will be triaging bugs. I've been putting this off because it's a bit tedious, but I'm likely going to start after this email and Just Do It. Prepare your inbox, depending on how well I can wield the 'bulk edit' feature. By the end of it, we should have an accurate depiction of what we want in 7.8.3. - On that note, we'll be using a new milestoning policy. Things filed at 7.4 stage will now be demoted in priority, since the 7.8 branch is done. The 7.6 tickets will NOT be re-milestoned at all - they could be young, and their priority shouldn't be touched unfairly and preemptively. Most people don't need to care about this, except possibly me and Herbert. But if you do want to move something around, please let me know, and I'll fill you in on the details. - I've been looking into our CI setup for GHC, and evaluating things. Right now though, I am directly working on getting Windows build bots set up on Gabor's infrastructure. He gave me the credentials, and hopefully this should not take long, it just slipped my mind. But mostly I've been looking at CI systems for Hackage, so that we can try to continuously integrate a subset of important packages against GHC over time. Right now, we have Travis-CI thanks to Herbert, but not quite everyone uses this (or doesn't properly configure it to e.g. test HEAD). This would really help find things in the future, I think, especially closer to release. It would also really help find nasty bugs in the RCs, like the dreaded #8978 Right now, after some thought, I'm looking into Michael's Stackage as a starting point for this, as he's done some awesome work. But I haven't yet done so in anger, and there are some other things I want to try too. ------------------------------------------------------------------------------------------ I think that's all for now. Do let me know if you have questions. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 5

Cross-compiling to Haiku
by Jessica Hamilton 26 Apr '14

26 Apr '14

Hi, I seem to have managed to build a cross-compiler for Haiku, but am having trouble installing it. Possibly I'm missing something during the build, which didn't get pointed out to me at the time. On the Linux host, the build was basically: export PATH=$PATH:/path/to/haiku/gcc4/cross-compiler ./configure --target=i586-pc-haiku --enable-unregisterised --prefix=/opt make make binary-dist In Haiku, after editing configure to set GHC_PWD=pwd (the bundled ghc_pwd is built for the host, not the target...), that part seems to go well. But in make install I get the following errors/output: > ./configure --prefix=/boot/home/config/non-packaged .... Configuration done, ready to 'make install' > make install make -r --no-print-directory -f ghc.mk install BINDIST=YES NO_INCLUDE_DEPS=YES ghc.mk:680: libraries/old-time/ghc.mk: No such file or directory ghc.mk:680: libraries/haskell98/ghc.mk: No such file or directory ghc.mk:680: libraries/haskell2010/ghc.mk: No such file or directory make[1]: *** No rule to make target `libraries/haskell2010/ghc.mk'. Stop. make: *** [install] Error 2 I presume those are the standard libraries it's trying to install? Jessica

2 1

RFC: template-haskell & Data.Map vs. Prelude.lookup use
by Herbert Valerio Riedel 25 Apr '14

25 Apr '14

Hello *, In order to address https://github.com/haskell/cabal/issues/1811 I've prepared a commit for review at https://git.haskell.org/ghc.git/commitdiff/refs/heads/wip/drop-containers-d… However, I'm wondering if we really need Data.Map, or if would be equally ok to simply use O(n) Prelude.lookup-style dictionary Does anyone here happen to have an estimate for how large the dictionary in https://git.haskell.org/ghc.git/blob/HEAD:/libraries/template-haskell/Langu… (which is the only use of Data.Map in TH) typically gets? Cheers, hvr

3 4