- ghc-devs - Haskell.org

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

Re: Build failure under Fedora 21
by Roman Cheplyaka 25 Jan '15

25 Jan '15

On 12/01/15 04:00, Dominick Samperi wrote: > Hi Roman. > > As I said in my comments I tried the binary distribution provided for > CentOS65 Linux but ran into problems. I also tried the distribution provided > for Debian Linux; this installed, but there were problems. > > Fedora is the most "cutting edge" distro, and there is no ghc binary > provided for it. I was able to build from source under Fedora 20 about a year > ago. % lsb_release -d Description: Fedora release 21 (Twenty One) % ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 There's no reason the binary ghc release shouldn't work for you (specifically, the deb7 one). What problems did you run into? (There's also no reason you shouldn't be able to build from source; but if all you want is just a working ghc installation, installing the bindist is much easier and faster.) Roman

5 8

SPARC NCG, how to debug load isn issue.
by Karel Gardas 24 Jan '15

24 Jan '15

Folks, from time to time I'm attempting to resurrect SPARC NCG. It looks like it's off by default since 7.4? release and I feel it's kind of pity. I've been able to hack it on 7.6.x and make it functional. I failed on 7.8 and later. Double float load was broken there. Now, I'm attempting on fairly recent GHC HEAD as of Jan 17 and I do have problem with illegal isn generated into the binary. This is caused by LD II64 ... Instr to be translated to SPARC ldd <addr>,g1 where g1 reg is not even, but odd and this fails as spec. says: " The load doubleword integer instructions (LDD, LDDA) move a doubleword from memory into an r register pair. The more significant word at the effective memory address is moved into the even r register. The less significant word (at the effective memory address + 4) is moved into the following odd r register. (Note that a load doubleword with rd = 0 modifies only r[1].) The least significant bit of the rd field is unused and should be set to zero by software. An attempt to execute a load doubleword instruction that refers to a mis-aligned (odd) destination register number may cause an illegal_instruction trap. " I've found out that the problematic source code is HeapStackCheck.cmm and the problematic piece is: if (Capability_context_switch(MyCapability()) != 0 :: CInt || Capability_interrupt(MyCapability()) != 0 :: CInt || (StgTSO_alloc_limit(CurrentTSO) `lt` (0::I64) && (TO_W_(StgTSO_flags(CurrentTSO)) & TSO_ALLOC_LIMIT) != 0)) { ret = ThreadYielding; goto sched; This "(0::I64)" causes it. So that's the problem description. Now I'm attempting to debug it a little bit to find out where the LD II64 Instr is generated and I'm not able to find single place which would looks familiar with asm I get here: .Lcq: ld [%i1+812],%g1 ldd [%g1+64],%g1 cmp %g1,0 bge .Lcs nop b .Lcr nop more importantly when I look into sparc's version on mkLoadInstr, I don't see any way how it may generate LD II64: sparc_mkLoadInstr dflags reg _ slot = let platform = targetPlatform dflags off = spillSlotToOffset dflags slot off_w = 1 + (off `div` 4) sz = case targetClassOfReg platform reg of RcInteger -> II32 RcFloat -> FF32 RcDouble -> FF64 _ -> panic "sparc_mkLoadInstr" in LD sz (fpRel (- off_w)) reg In whole SPARC NCG I've found the only place which clearly uses LD II64 and this is in Gen32.hs for loading literal float into reg: getRegister (CmmLit (CmmFloat d W64)) = do lbl <- getNewLabelNat tmp <- getNewRegNat II32 let code dst = toOL [ LDATA ReadOnlyData $ Statics lbl [CmmStaticLit (CmmFloat d W64)], SETHI (HI (ImmCLbl lbl)) tmp, LD II64 (AddrRegImm tmp (LO (ImmCLbl lbl))) dst] return (Any FF64 code) It's interesting but also iselExpr64 which should be probably here for manipulating 64bit data on 32bit platform, so even this is using pairs of LD II32 Instrs instead of single LD II64.... So I'm kind of out of idea where the LD II64 gets in the flow and is later translated into ldd with problematic reg. Do you have any idea how to debug this issue? Or do you have any idea where to read more about general structure of NCG, I've already seen https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/NCG -- but this is kind of dated... Thanks for any idea how to proceed! Karel

1 0