- ghc-devs - Haskell.org

Make one-shot a per-registration property
by Kazu Yamamoto 30 Jan '15

30 Jan '15

Hi, This is just confirmation. Ben's one-shot patch (*1) is included in master but not included in the ghc-7.10 branch. Is this intentional? Is it supposed to be merged in GHC 7.12? (*1) 023439980f6ef6ec051f676279ed2be5f031efe6 https://phabricator.haskell.org/D347 --Kazu

4 4

the performance of IO manager in GHC 7.10.1rc2
by Kazu Yamamoto 30 Jan '15

30 Jan '15

Hi, As usual, I took benchmark of IO manager to check if preformance regression is introduced. Fortunately, I don't see any preformance regression. +RTS -N<x> 1 2 4 8 16 --------------------------------------------------------- GHC7.8.4 81,413 153,478 270,178 406,448 50,3203 GHC7.10.1rc2 88,247 148,471 265,392 409,514 49,3890 Environment: two real 20 cores machines directly connected by 20G - Xeon E5-2650Lv2 (1.70GHz/10cores/25MB) x 2, 8GM, no HT - CentOS 7.0 - Two 10Gs are aggregated Server: witty -a -m -r 8080 +RTS -A32m -N<x> Benchmark: weighttp -n 100000 -c 1000 -k -t 16 http://<ip-addr>/ P.S. If Ben's patch will be included in GHC 7.10, I will try this again. --Kazu

2 2

A simpler ORF
by Iavor Diatchki 29 Jan '15

29 Jan '15

Hello, I've been following the various discussions about changes to Haskell's record system, and I find that most of the current proposals are fairly complex, especially for the benefit they provide. I use Haskell records a lot, and I've been wondering if there might be a simpler alternative, one that: 1. will allow us to reuse field names across records 2. does not require any fancy types 3. it will not preclude continued research on "the right" way to get more type-based record resolution. Based on designs I've seen in the past, my experience with Haskell records, and discussions with colleagues, I put together a document describing a potential design that, I think, satisfies goals 1 to 3: https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Simple I think the proposal should be fairly simple to implement, and I'd be willing to do it, if there is enough support from the community. Let me know what you think! -Iavor

5 5

Put "Error:" before error output
by Konstantine Rybnikov 28 Jan '15

28 Jan '15

Hi! I'm bringing this up once again. Can we add "Error:" in the output of an error in a similar way ghc shows "Warning:" for warnings? Main reasoning is that, for example, on a build-server, where you have lots of cores to build your program, if you get an error, it gets lost somewhere in the middle of compiler's output in all other "Warning" messages you get, since error is not always shown last on multi-core build. Thanks.

7 12

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2
by George Colpitts 28 Jan '15

28 Jan '15

On Tuesday, January 27, 2015, George Colpitts <george.colpitts(a)gmail.com> wrote: > Thanks Carter!! llvm 3.5.1 fixed my llvm problem > That leaves one issue with ghci and the normal compiler > > - calling main from the ghci interpreter after loading *compiled* code > results in > - Prelude Main> main > Too late for parseStaticFlags: call it before runGhc or runGhcT > *** Exception: ExitFailure 1 > > > > On Tue, Jan 27, 2015 at 10:11 PM, George Colpitts < > george.colpitts(a)gmail.com > <javascript:_e(%7B%7D,'cvml','george.colpitts(a)gmail.com');>> wrote: > >> I have llvm 3.4.2. Not sure why I thought that was the supported version. >> Where would that be documented? There doesn't seem to be anything on this >> in >> https://downloads.haskell.org/~ghc/7.10.1-rc1/docs/html/users_guide/release… >> >> There is lots of mail about llvm. I guess the following from Ben Gamari >> on 11/28 implies llvm 3.5. I couldn't find anything more definitive. >> >> Once I get a definitive answer I will try again assuming the answer is >> not 3.4.2 >> >> To summarize, >> >> * it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework >> when the `$def` symbols are marked as internal >> >> * ARM is broken (again) due to a bug in the GHC calling convention >> implementation; an LLVM fix is waiting to be merged >> >> * I have code reworking TNTC for LLVM 3.6; unfortunately LLVM 3.6 >> support will likely need to wait until 7.12 >> >> * Austin's LLVM packaging proposal seems very much like the right way >> forward >> >> * Anticipating this proposal, I have started collecting [2] >> optimization passes >> >> Cheers, >> >> >> >> On Tue, Jan 27, 2015 at 9:52 PM, Carter Schonwald < >> carter.schonwald(a)gmail.com >> <javascript:_e(%7B%7D,'cvml','carter.schonwald(a)gmail.com');>> wrote: >> >>> George, what version of llvm are you using? afaik, only llvm 3.5 is >>> supported for 7.10 (though I could be wrong) >>> >>> On Tue, Jan 27, 2015 at 8:39 PM, George Colpitts < >>> george.colpitts(a)gmail.com >>> <javascript:_e(%7B%7D,'cvml','george.colpitts(a)gmail.com');>> wrote: >>> >>>> Has anybody successfully build and used this on the Mac on 10.10 using >>>> the latest XCode? While it is better than RC1 I am still seeing the >>>> following two issues: >>>> >>>> >>>> - programs compiled with llvm fail at runtime with illegal >>>> instruction >>>> - calling main from the ghci inerpreter after loading compiled code >>>> results in >>>> - Prelude Main> main >>>> Too late for parseStaticFlags: call it before runGhc or runGhcT >>>> *** Exception: ExitFailure 1 >>>> >>>> Instead of solving the above, I'd be happy to switch to a Mac OS >>>> bindist and see if I have the same problems there. Do we have an ETA for a >>>> Mac OS bindist? >>>> >>>> >>>> Thanks >>>> >>>> George >>>> >>>> >>>> On Mon, Jan 26, 2015 at 8:13 PM, Austin Seipp <austin(a)well-typed.com >>>> <javascript:_e(%7B%7D,'cvml','austin(a)well-typed.com');>> wrote: >>>> >>>>> We are pleased to announce the second release candidate for GHC 7.10.1: >>>>> >>>>> https://downloads.haskell.org/~ghc/7.10.1-rc2/ >>>>> >>>>> This includes the source tarball and bindists for 64bit/32bit Linux >>>>> and Windows. Binary builds for other platforms will be available >>>>> shortly. (CentOS 6.5 binaries are not available at this time like they >>>>> were for 7.8.x). These binaries and tarballs have an accompanying >>>>> SHA256SUMS file signed by my GPG key id (0x3B58D86F). >>>>> >>>>> We plan to make the 7.10.1 release sometime in February of 2015. >>>>> >>>>> Please test as much as possible; bugs are much cheaper if we find them >>>>> before the release! >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> Austin Seipp, Haskell Consultant >>>>> Well-Typed LLP, http://www.well-typed.com/ >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs(a)haskell.org >>>>> <javascript:_e(%7B%7D,'cvml','ghc-devs(a)haskell.org');> >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>> >>>> >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs(a)haskell.org >>>> <javascript:_e(%7B%7D,'cvml','ghc-devs(a)haskell.org');> >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>>> >>> >> >

1 0

GHC Weekly News - 2015/01/27
by Austin Seipp 27 Jan '15

27 Jan '15

Hi *, It's time for the weekly GHC news. Over at GHC HQ, we discussed some things this week including: - Austin took the time the past week to check `./validate --slow` failures, and is planning on filing bugs and fixes for the remaining failures soon. Afterwords, we'll immediately begin enabling `--slow` on Phabricator, so developers get their patches tested more thoroughly. - The 7.10 release looks like it will likely not have a 3rd Release Candidate, and will be released in late Feburary of 2015, as we originally expected. - The 7.10 branch currently has two showstopping bugs we plan on hitting before the final release. And we'd really like for users to test so we can catch more! - Austin Seipp will likely be gone for the coming week in a trip to New York City from the 28th to the 4th, meaning (much to the dismay of cheering crowds) you'd better catch him beforehand if you need him! (Alternatively Austin will be held back due to an intense snowstorm developing in NYC. So, we'll see!) - Austin is planning on helping the LLVM support in HEAD soon; after coordinating with Ben Gamari, we're hoping to ship GHC 7.12 with (at least) LLVM 3.6 as an officially supported backend, based on the documentation described in https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend - lots of thanks to Ben for working with upstream to file bugs and improve things! And in other news, through chatter on the mailing list and Phabricator, we have: - Austin Seipp announced GHC 7.10.1 RC2: https://www.haskell.org/pipermail/ghc-devs/2015-January/008140.html - Peter Trommler posted his first version of a native Linux/PowerPC 64bit code generator! There's still a lot more work to do, but this is a significantly improved situation over the unregisterised C backend. Curious developers can see the patch at Phab:D629. - A long, ongoing thread started by Richard Eisenberg about the long-term plans for the vectorisation code have been posted. The worry is that the vectoriser as well as DPH have stagnated in development, which costs other developers any time they need to build GHC, make larger changes, or keep code clean. There have been a lot of varied proposals in the thread from removing the code to commenting it out, to keeping it. It's unclear what the future holds, but the discussion still rages on. https://www.haskell.org/pipermail/ghc-devs/2015-January/007986.html - Karel Gardas is working on reviving the SPARC native code generator, but has hit a snag where double float load instructions were broken. https://www.haskell.org/pipermail/ghc-devs/2015-January/008123.html - Alexander Vershilov made a proposal to the GHC team: can we remove the `transformers` dependency? It turns out to be a rather painful dependency for users of the GHC API and of packages depending on `transformers`, as you cannot link against any version other than the one GHC ships, causing pain. The alternative proposal involves splitting off the `transformers` dependency into a package of Orphan instances. The final decision isn't yet clear, nor is a winner in clear sight yet! https://www.haskell.org/pipermail/ghc-devs/2015-January/008058.html - Konstantine Rybnikov has a simple question about GHC's error messages: can they say `Error:` before anything else, to be more consistent with warnings? It seems like a positive change - and it looks like Konstantine is on the job to fix it, too. https://www.haskell.org/pipermail/ghc-devs/2015-January/008105.html - Simon Marlow has started a long thread about the fate of records in future GHC versions. Previously, Adam Gundry had worked on `OverloadedRecordFields`. And now Nikita Volkov has introduced his `records` library which sits in a slightly different spot in the design space. But now the question is - how do we proceed? Despite all prior historical precedent, it looks like there's finally some convergence on a reasonable design that can hit GHC in the future. https://www.haskell.org/pipermail/ghc-devs/2015-January/008049.html Closed tickets the past two weeks include: #9889, #9384, #8624, #9922, #9878, #9999, #9957, #7298, #9836, #10008, #9856, #9975, #10013, #9949, #9953, #9856, #9955, #9867, #10015, #9961, #5364, #9928, and #10028. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Looking up importDecl and Unique inequality
by Moritz Angermann 27 Jan '15

27 Jan '15

Hi *, I'm still trying to get a stage1 compiler with TH support. After some experimenting, I managed to adjust ghc-7.8 sufficiently to build and not complain about compiling TH code right away. I'm now stuck with importDecl trying to import Language.Haskell.TH.Lib.ExpQ (as that is referenced in my sample code I try to compile), but even after loading the TH/Lib.hi file unable to find it due to a missmatch in the Uniques. I have a Stage 2, ghc-7.8 (A) compiler for the host, which I use to compile a Stage 1 ghc-7.8 (B) compiler. Now I want to inject some code (a plugin) into (B), which therefore is compiled with (A) and hence depends on the packages of (A). But as A and B are the identical version, I hope that I should be able to feed (B) the same package db. Given that the plugin was compiled into a cabal package with (A) at (Y) and the package db of (A) is at (X), I try to compile my sample code with $ cabal exec B -- path/to/Sample.hs -package-db X -package-db Y -package plugin -fplugin MyPlugin -- Sample.hs -- {-# LANGUAGE TemplateHaskell #-} module Main where main :: IO () main = do let e = $([|Just "Splice!"|]) :: Maybe String putStrLn . show $ e -- Sample.hs -- The type checker tries to find Language.Haskell.TH.Lib.ExpQ and loads the lib/TH.hi from (X) with the declaration, but fails to find it in the eps_PTE after loading the interface. What I was able to figure out was that Language.Haskell.TH.Lib.ExpQ loaded from lib/TH.hi in (X) obtains the unique key "rCM", while the unique key that is being looked up is "39S". Can someone shed some light onto where I am misunderstanding how something is supposed to work? Cheers, Moritz

1 0

Re: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match
by Alan & Kim Zimmerman 27 Jan '15

27 Jan '15

No problem, I will work around it, I originally did not want to do it because of potential destabilisation, this still holds. On Tue, Jan 27, 2015 at 12:08 PM, GHC <ghc-devs(a)haskell.org> wrote: > #9988: Remove fun_id, is_infix from FunBind, as they are now in Match > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: task | Status: new > Priority: normal | Milestone: 7.12.1 > Component: Compiler | Version: 7.10.1-rc1 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > Type of failure: None/Unknown | Unknown/Multiple > Blocked By: | Test Case: > Related Tickets: | Blocking: > | Differential Revisions: > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > 7.10 is in RC2. We can't keep modifying it otherwise we will never get it > out. I suppose that if you have strong reason to believe that you are not > introducing new bugs, and having it in is going to transform your life for > the better, then you can make the case. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9988#comment:6> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

American vs. British English
by Jan Stolarek 27 Jan '15

27 Jan '15

I just realized GHC has data types named FamFlavor and FamFlavour. That said, is there a policy that says which English should be used in the source code? Janek

6 6

Re: GHC support for the new "record" package
by David Feuer 27 Jan '15

27 Jan '15

>> I don?t think anyone is suggesting adding any of lens are they? Which >> bits did you think were being suggested for addition? >> > I was mostly referring to the use of the (a -> f b) -> s -> f t form. All right. If nobody's suggesting it, I'll suggest it. Is it really that evil? Why does it occupy such a strange place off to the side of the rest of the Haskell ecosystem? David

2 1