June 2015 - ghc-devs - Haskell.org

RE: [Diffusion] [Build Failed] rGHC0aaea5b8345f: Tiny refactor plus comments
by Simon Peyton Jones 29 Jun '15

29 Jun '15

The builds seem to be failing with perf failures for haddock.Cabal haddock.compiler but that doesn't seem to happen for me. It looks as though it started with rGHC*rGHC0b7e538a09bc: Allow recursive unwrapping of data families but since I can't reproduce it, it's hard to investigate. I can't even see what performance number has changed, because harbourmaster only shows the tail of the log. Any insight from others would be useful. Joachim: do the nofib logs show any changes? Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 26 June 2015 16:47 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC0aaea5b8345f: Tiny refactor | plus comments | | Harbormaster failed to build B4562: rGHC0aaea5b8345f: Tiny refactor | plus comments! | | BRANCHES | master | | USERS | simonpj (Author) | GHC - Type checker/inferencer (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC0aaea5b8345f | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Type checker/inferencer

3 4

arc land failing
by Simon Marlow 29 Jun '15

29 Jun '15

I haven't been able to arc land in GHC for a while, it always complains about not being able to fast-forward, like this: $ git pull --rebase First, rewinding head to replay your work on top of it... Applying: Mask to avoid uncaught ^C exceptions $ arc land Landing current branch 'ghci-mask'. Switched to branch master. Updating branch... Switched back to branch ghci-mask. Exception Command failed with error #128! COMMAND git pull --ff-only --no-stat STDOUT (empty) STDERR fatal: Not possible to fast-forward, aborting. (Run with --trace for a full exception trace.) [1] 11904 exit 1 arc land Anyone able to look into this? Cheers, Simon

1 0

Re: Abstract FilePath Proposal
by Boespflug, Mathieu 29 Jun '15

29 Jun '15

On 28 June 2015 at 16:34, Sven Panne <svenpanne(a)gmail.com> wrote: > 2015-06-28 12:03 GMT+02:00 Boespflug, Mathieu <m(a)tweag.io>: >> >> why does the proposal *not* include normalization? [...] > > > I think this is intentional, because otherwise we are in the IO monad for > basically all operations. What's the normalized representation of > "foo/bar/../baz"? Notice that the kind of normalization I'm talking about, specified in the link I provided, does not include this kind of normalization. Because it requires the IO monad to perform correctly, and only on real paths. Here is the link again: https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-P… Full canonicalization of paths, stripping out redundant ".." and whatnot, should certainly be done in a separate function, in IO.

4 4

Different behavior in ghci 7.8.3 vs 7.10.1?
by Dominick Samperi 27 Jun '15

27 Jun '15

Hello, I'm trying to run code that works with ghci 7.8.3 under ghci 7.10.1 but this fails. Under 7.8.3, when I run from the shell: export LD_LIBRARY_PATH=thepath ghci -lmylib -fno-ghci-sandbox mydriver.hs I see the usual startup diagnostics along with Loading object (dynamic) mylib ... done final link ... done [1 of 1] Compiling Main Main> But under 7.10.1, when I do the same, there is no indication that linking happens, and when I try to run the program there are undefined references. I probably missed the post that explains this behavior. Can somebody provide a pointer to a work-around? Thanks, Dominick

2 8

help with recognizing symbolic identifiers
by Richard Eisenberg 27 Jun '15

27 Jun '15

Hi devs, I've just posted #10583 (http://ghc.haskell.org/trac/ghc/ticket/10583) about fixing up basicTypes/Lexeme.hs. As stated in the ticket, I'm happy to do the hacking, but I need some advice. My most pressing question is this: Examine the following functions, which all should do the same thing * isVarSymChar: https://github.com/ghc/ghc/blob/master/compiler/basicTypes/Lexeme.hs#L102 * okSymChar: https://github.com/ghc/ghc/blob/master/compiler/basicTypes/Lexeme.hs#L215 * notFollowedBySymbol: https://github.com/ghc/ghc/blob/master/compiler/parser/Lexer.x#L904 These functions intend to identify characters that can appear in symbolic identifiers. They all have different implementations. Which one is right? Or is there a better way to do this operation? There are other questions in the ticket, but I can probably sort those out on my own. If you can help, ideally you will respond in the ticket itself. Many thanks! Richard

1 0

expanding type synonyms in error messages
by Ömer Sinan Ağacan 26 Jun '15

26 Jun '15

Hi all, While working with complex types with lots of arguments etc. errors are becoming annoying very fast. For example, GHC prints errors in this way: Expected type: <type without any synonyms> Actual type: <type with synonyms> Now I have to expand that synonym in my head to understand the error. I was wondering if implementing something like this is possible: In type error messages, GHC also prints types that are cleaned from type synonyms. Maybe something like this: Expected type: <type1> (without synonyms): <type1, synonyms are expanded> Actual type: <type2> (without synonyms): <type2, synonyms are expanded> If this is not always desirable for some reason, we can hide this behavior behind a flag. What do GHC devs think about this? Is this, in theory, possible to do? How hard would it be to implement this? Thanks.

6 13

Template Haskell working group
by Simon Peyton Jones 26 Jun '15

26 Jun '15

Friends I'm looking for someone, or a small group, to act as a Supreme Being for Template Haskell. Might you be willing? There is a steady trickle of bug reports / feature requests relating to Template Haskell, which I find that I simply don't have the time to pay proper attention to. Here is a recent example http://ghc.haskell.org/trac/ghc/ticket/10572. But if no one pays attention, they languish. None of them is very hard, but all require a little careful thought. What should the Template Haskell API be like? What semantics do we want? My hope is that if someone, or a small group, felt mandated to push TH forward, then we might make some progress. At the moment I have the uneasy feeling that while everyone can make suggestions, it's all waiting for SPJ to decide something, and SPJ is not paying enough attention. I don't want to be a bottleneck. Moreover, since I'm not a heavy-duty TH user, I'm poorly placed to make design choices. The reason I'm optimistic is because the steady trickle tells me that TH is in fact highly valued and widely used. So perhaps among that group there are some people who would be willing to debate alternative designs, make choices, and implement them. I would be more than willing to act as consultant, both on design and implementation. GHC absolutely relies on its community. Please consider making an offer to help. Thanks! Simon

2 3

RE: ANNOUNCE: GHC 7.10.2 Release Candidate 1
by Tamar Christina 21 Jun '15

21 Jun '15

For the Windows users: I have pushed GHC to the chocolatey package manager. You can find the packages including this rc1 here https://chocolatey.org/packages/ghc cinst ghc -pre To install it. The rest of the packages are still under moderation so until then you need to specify the full version of the one you want. Tamar Sent from my Windows Phone ------------------------------ From: Mark Lentczner <mark.lentczner(a)gmail.com> Sent: ‎6/‎15/‎2015 21:02 To: ghc-devs(a)haskell.org; haskell-platform(a)projects.haskell.org Subject: Re: ANNOUNCE: GHC 7.10.2 Release Candidate 1 And the Windows install for HP 7.10.2 RC1 is out too: HaskellPlatform-7.10.1.20150612-x86_64-setup.exe <http://www.ozonehouse.com/mark/platform/HaskellPlatform-7.10.1.20150612-x86…> 08c5f2168bdf9147b548263d2b45e1db6b602830002f27bbbbf92bf066b761f0 HaskellPlatform-7.10.1.20150612-x86_64-setup.exe

1 0

Re: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround
by George Colpitts 20 Jun '15

20 Jun '15

7.10.1.20150612 It's very sensitive, I see today. Sometimes it fails with Simplifier ticks exhausted other times it works. Bizarre I think the latter is the more common case and I think the former case has something to do with existing .o file or order of args and -fforce-recomp may mean it always works but that is very speculative. The two casesor $ time ghc -fno-specialise -O2 Slice.hs [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, Slice.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150612 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_s1FS5 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 1668604 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug real 0m19.714s user 0m18.264s sys 0m0.875s $ time ghc -O2 -fno-specialise Slice.hs [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, Slice.o ) real 0m3.228s user 0m3.040s sys 0m0.155s On Sat, Jun 20, 2015 at 2:03 PM, GHC <ghc-devs(a)haskell.org> wrote: > #10491: Regression, simplifier explosion with Accelerate, cannot compile, > increasing tick factor is not a workaround > -------------------------------------+------------------------------------- > Reporter: robertce | Owner: > Type: bug | Status: new > Priority: highest | Milestone: 7.10.2 > Component: Compiler | Version: 7.10.1 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > Type of failure: Compile-time | Unknown/Multiple > performance bug | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Revisions: > -------------------------------------+------------------------------------- > > Comment (by bgamari): > > George, what GHC version did you test `-fno-specialise` on? While > yesterday I was able to confirm that `-fno-specialise` seemed to make no > difference on a test machine running what should have been 7.10.1 I am now > having trouble replicating this on my laptop. Unfortunately I no longer > have access to the test environment on which I tested this yesterday but > clearly something was inconsistent. > > I am now seeing on multiple machines that `-fno-specialise` indeed allows > things to compile, > {{{ > $ ghc -V > The Glorious Glasgow Haskell Compilation System, version 7.10.1 > $$ time ghc Slice.hs -fforce-recomp -O2 -fno-specialise > [1 of 1] Compiling Slice ( Slice.hs, Slice.o ) > > real 0m3.759s > user 0m1.688s > sys 0m0.044s > $ time ghc Slice.hs -fforce-recomp -O2 > [1 of 1] Compiling Slice ( Slice.hs, Slice.o ) > ^C > > real 0m51.103s > user 0m44.336s > sys 0m0.948s > }}} > > I am now looking at whether disabling only cross-module specialisation is > enough to eliminate the blow-up. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10491#comment:27> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

RFC: "Native -XCPP" Proposal
by Herbert Valerio Riedel 19 Jun '15

19 Jun '15

Hello *, As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor. This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed for use with C's tokenizer has caused already quite some problems[1] in the past. I'd like to see GHC 7.12 adopt an implemntation of `-XCPP` that does not rely on the shaky system-`cpp` foundation. To this end I've created a wiki page https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp to describe the actual problems in more detail, and a couple of possible ways forward. Ideally, we'd simply integrate `cpphs` into GHC (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be discussed and debated since affects the overall-license of the GHC code-base, which may or may not be a problem to GHC's user-base (and that's what I hope this discussion will help to find out). So please go ahead and read the Wiki page... and then speak your mind! Thanks, HVR [1]: ...does anybody remember the issues Haskell packages (& GHC) encountered when Apple switched to the Clang tool-chain, thereby causing code using `-XCPP` to suddenly break due to subtly different `cpp`-semantics?

15 19