- ghc-devs - Haskell.org

RE: Which language extensions to register for Cabal 1.22?
by Simon Peyton Jones 19 Dec '14

19 Dec '14

| ...which of the following language extensions (which are mentioned in | T4437) are deemed stable enough to be registered in Cabal for GHC | 7.10? I'm not sure what criteria you'd like to use! PatternSynonyms, PartialTypeSignatures, and NamedWildCards are all pretty stable and should go in. StaticPointers will definitely continue to be there in future; but the details of the API may change, and the current implementation is very much a prototype. DeriveAnyClass: I defer to Pedro Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 18 December 2014 22:14 | To: Simon Peyton Jones | Cc: Johan Tibell; Austin Seipp; Duncan Coutts | Subject: Which language extensions to register for Cabal 1.22? | | Hello Simon, | | ...which of the following language extensions (which are mentioned in | T4437) are deemed stable enough to be registered in Cabal for GHC | 7.10? | | - "DeriveAnyClass" | - "PatternSynonyms" | - "PartialTypeSignatures" | - "NamedWildcards" | - "StaticPointers" | | Cheers, | hvr

2 1

Re: performance regressions
by Ben Gamari 19 Dec '14

19 Dec '14

Joachim Breitner <nomeata(a)debian.org> writes: > Hi, > > Am Montag, den 15.12.2014, 10:58 -0500 schrieb Ben Gamari: >> >> - Travis has not picked up on these errors. >> > >> > unfortunately, travis is slighly less useful since a few weeks due to >> > T5681 failing (possibly due to the use of LLVM-3.4), but I’m still >> > waiting for an reply on that issue. >> > >> You aren't looking for a response from me on this, are you? I just >> checked and I don't seem to have any outstanding messages from you but >> it's entirely possible I overlooked something. > > this is independent of our arm issues, and I think a tad older; I did > not direct it to anyone specific. > > But I guess you are likely a person that can tell what’s wrong here: > > Am Sonntag, den 30.11.2014, 20:01 +0100 schrieb Joachim Breitner: >> Compile failed (status 256) errors were: >> /tmp/ghc16123_0/ghc16123_5.s: Assembler messages: >> >> /tmp/ghc16123_0/ghc16123_5.s:26:0: >> Error: can't resolve `.rodata' {.rodata section} - `Main_zdwwork_info$def' {.text section} >> >> /tmp/ghc16123_0/ghc16123_5.s:46:0: >> Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def' {.text section} >> >> /tmp/ghc16123_0/ghc16123_5.s:66:0: >> Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def' {.text section} >> >> /tmp/ghc16123_0/ghc16123_5.s:86:0: >> Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def' {.text section} >> >> /tmp/ghc16123_0/ghc16123_5.s:106:0: >> Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def' {.text section} >> >> /tmp/ghc16123_0/ghc16123_5.s:126:0: >> Error: can't resolve `.rodata' {.rodata section} - `ZCMain_main_info$def' {.text section} >> >> *** unexpected failure for T5681(optllvm) >> >> https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt >> >> Any ideas? > > Is it possible that this is due the llvm version used? Do we support 3.4 > in GHC HEAD? > > Using LLVM tools > llc : /usr/local/clang-3.4/bin/llc > opt : /usr/local/clang-3.4/bin/opt > > (http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html > does not talk about GHC HEAD explicitly. Should I look at the 7.10 > row? Does that mean that 3.4 is not supported? Shouldn’t the build > system, or at least the compiler, fail harder and more helpfully in > this case?) > LLVM 3.4 appears to have an unfortunate behavior whereby it will lose track of which section symbols with Internal linkage belong. I haven't had a chance to delve into this too deeply, however given that both 3.3 and 3.5 behave as expected I'm pretty sure this a bug. There are a few options here, a. Mark the `$def` symbols as ExternallyVisible, working around the issue at the expense of exposing internal symbols to the outside world. b. Mark LLVM 3.4 as unsupported At the moment I'm leaning towards (b) since I haven't had a chance to think through the implications of (a); if nothing else I suspect this wouldn't help the DLL symbol table size issues on Windows. Giving up on LLVM 3.4 might be unfortunate for a good number of users, however. Ultimately this underlines the need to package LLVM with GHC. Cheers, - Ben

8 14

Can we rename completion to autocomplete
by Edward Z. Yang 19 Dec '14

19 Dec '14

I keep typing 'comp<TAB>' and expecting it to autocomplete to compiler, and this is stopped working. Can we rename the 'completion' directory to something? How about 'autocomplete'? Thanks, Edward

4 4

GHC Weekly News - 2014/12/16
by Austin Seipp 18 Dec '14

18 Dec '14

Hi *, time for another piece of the GHC weekly news! - Joachim Breitner has gotten the new GHC 7.8.4 package to tentatively build on ARM quite easily for Debian. Austin also took the liberty of merging all the needed patches; they'll be part of the 7.8.4 release https://www.haskell.org/pipermail/ghc-devs/2014-December/007608.html - Greg Weber announced he's taken the time to set up a Docker image for GHC development - if you're on Linux, Greg's image should help you get up to speed with a GHC development environment in minutes! https://www.haskell.org/pipermail/ghc-devs/2014-December/007606.html - Lennart Kolmodin has spent time working on autocompletion for GHC, and 7.10 will ship with bash completion scripts - which package maintainers and distributions can now ship for their users. Thank you Lennart! https://www.haskell.org/pipermail/ghc-devs/2014-December/007614.html - Adam Gundry has a question about the new type checker plugin infrastructure; in particular - how do we deal with the serialization of type checker evidence that plugins may want to create or pass around on their own? Richard, Simon and Iavor weigh in. https://www.haskell.org/pipermail/ghc-devs/2014-December/007626.html - For the past few days, Richard Eisenberg has been hunting a performance regression in the compiler. After profiling, discussion on IRC and elsewhere, Richard has finally made some headway, and discovered one of the 'hot spots' in his patch. Unfortunately the battle isn't quite over just yet, and the hunt for a few more % increase remains. https://www.haskell.org/pipermail/ghc-devs/2014-December/007645.html - David Spies has hit a very strange situation with GHC 7.8.3 running out of memory. But it turned out this was a change in 7.8, in relation to how stacks were managed. Phew! https://www.haskell.org/pipermail/ghc-devs/2014-December/007646.html - Austin made a final call for 7.8.4 bugfixes. He plans on making the final release this week, if nobody has any other major complaints. https://www.haskell.org/pipermail/ghc-devs/2014-December/007684.html Finally, in a slight change, we'll also be covering some notes from this week's meeting between GHC HQ (Austin, Simon PJ, SimonM, Herbert and Mikolaj), including... - The 7.10 RC1 looks like it's scheduled to occur this week still; all of our libraries and submodules are up-to-date, and we've taken the time to alert all of our maintainers about this. Thanks to Herbert for taking control of this! - We'll soon be implementing a new 'push hook' for the `ghc.git` repository: no more trailing whitespace. Since we've recently detabbed, and de-lhs-ified the tree, a knock-on effect was deleting trailing whitespace. Now that we've done a lot of this, we should take the time to enforce it - so they can't slip back in. - Austin will be landing Phab:D169 and Phab:D396 soon to get it into 7.10.1 RC1. - This week, Austin managed to secure two sponsors for GHC/Haskell.org. We've been given a wonderful set of ARM buildbots (running in the cloud!) and a new, incredibly powerful POWER8 machine to use (with over 170 hardware threads available, for scalability testing). Hooray for our friends at Online.net and RunAbove.com for helping us out! Closed tickets this week include: #9871, #9808, #9870, #9605, #9874, #9872, #9090, #9404, #8240, #9567, #9566, #9583, #9117, #9882, #9884, #9372, #7942, #8951, #9817, #9620, #9336, #9523, #9552, #8988, #9390, #9415, #9371, #7143, #9563, #8778, #4428, #4896, #9393, #9169, #7015, #8943, #8621, #9132, #9857, #8024, #9831, and #9888. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2

RFC: Remove -fwarn-unticked-promoted-constructors from -Wall
by Jan Stolarek 18 Dec '14

18 Dec '14

We recently got a new warning -fwarn-unticked-promoted-constructors (see #9778 and D534). This warning is enabled with -Wall but I think that this is not a good idea. I strongly propose to remove it with -Wall. Rationale: 1. I feel that ticks add unnecessary noise: prDictOfPReprInstTyCon :: Type -> CoAxiom 'Unbranched -> [Type] -> VM CoreExpr To me it feels awkward to have Unbranched with a tick but CoreExpr without a tick (both are types after all). Moreover, ticks also trip many syntax highlighters, which further degrades code readability. 2. I've been refactoring some of GHC code to use promoted types instead of empty data types (see CoAxiom.BranchList). This would have been a fairly local change, except that I have to add ticks in every place that mentiones promoted types. That's a Royal Pain and a "good" example how this warning can get in people's way. Janek

2 1

are patterns synonyms definable in GHCI?
by Carter Schonwald 18 Dec '14

18 Dec '14

Hey all, I was trying to define some pattern synonyms in ghci recently, and that doesnt seem to work. Is that something slated to be fix in 7.10 or something?

5 7

Status updates
by Austin Seipp 18 Dec '14

18 Dec '14

Hi *, Here are some status updates: - I've merged the Applicative Monad patchset! Yay! Many thanks to Nathan Howell for helping me out in the end there. Please let me know if anything explodes horribly (I hope not). - Gabor has set up some build documentation for us based on HEAD, hooray! See here - http://haskell.inf.elte.hu/ - I still need to fix haskell.org/ghc to link to this properly (there may be other dead links, please let me know). - As I'm sure most of you were aware, it was a slow week due to ICFP & related events being most of last week. - As I'm also sure you were aware, Haskell.org suffered a lot of instability this past week. I've been focusing most of my efforts since about Thursday on this, since it's come and gone a lot and has needed some consistent monitoring. Unfortunately, it is not done yet, and there is still more work to be done. :( - ghc.haskell.org was migrated to a new server in the US as a part of this effort this weekend (send a thanks to Herbert). In general, you should notice nothing really new, but latency for UK citizens may be a bit higher than it was before now. - Now that Applicative/Monad is done, there are some more changes to 'base' that will happen (Bifunctors, Foldable/Traversable) that will need to happen. So I'm sure this discussion will start soon. - I still can't set up the Windows bot yet, sorry! Phabricator work is still not yet available upstream. Hopefully soon. - Sergei spent some time filing bugs that we should fix in the testsuite, because they fail --slow validate. I believe these are two of them: - https://ghc.haskell.org/trac/ghc/ticket/9567 - https://ghc.haskell.org/trac/ghc/ticket/9566 We'll probably need to fix these before we turn it on. Simon, these look like something up your alley... - For those who missed ICFP, Simon gave a nice status update for GHC, which is on YouTube: https://www.youtube.com/watch?v=Ex79K4lvJno&list=PL4UWOFngo5DW6nKDjK0UB5Oy9… -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

6 7

Understanding DsMeta module
by Jan Stolarek 18 Dec '14

18 Dec '14

I'm implementing Template Haskell support for injective type families and I'm struggling to understand DsMeta module. It seems that all functions in that module delegate their calls to functions in Language.Haskell.TH.Lib via wired-in names and the `DsMeta.rep2` function. I'm puzzled by this design and I'd appreciate if someone could explain why things are done this way. Take this function example: repPlainTV :: Core TH.Name -> DsM (Core TH.TyVarBndr) repPlainTV (MkC nm) = rep2 plainTVName [nm] where `plainTvName` is a name of `Language.Haskell.TH.Lib.plainTV`: plainTV :: Name -> TyVarBndr plainTV = PlainTV Why not implement repPlainTV like this: ? repPlainTV :: Core TH.Name -> DsM (Core TH.TyVarBndr) repPlainTV (MkC nm) = return $ MkC (TH.PlainTV nm) Janek

3 4

Re: [Diffusion] [Build Failed] rGHC726ea08a6e58: Amend TcPluginM interface
by Adam Gundry 18 Dec '14

18 Dec '14

On 18/12/14 09:25, Phabricator wrote: > Harbormaster failed to build B2694: rGHC726ea08a6e58: Amend TcPluginM interface! Sigh. It seems perf/compiler T3294 is failing on Harbormaster, but it validated fine locally on x86_64. I doubt my commit is responsible, and suspect this is just a wobbly test, but it's hard to know without the full build log. Is there a way to get full logs for failing Harbormaster builds? They seem to be uploaded only if the build succeeds. Thanks, Adam > USERS > adamgundry (Author) > GHC - Driver (Auditor) > GHC - Type checker/inferencer (Auditor) > > COMMIT > https://phabricator.haskell.org/rGHC726ea08a6e58 > > EMAIL PREFERENCES > https://phabricator.haskell.org/settings/panel/emailpreferences/ > > To: adamgundry, GHC - Driver, GHC - Type checker/inferencer -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

RE: type-checker regression in GHC HEAD?
by Simon Peyton Jones 17 Dec '14

17 Dec '14

Ah yes! A palpable bug thank you. Fixing.. S | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 17 December 2014 10:01 | To: Simon Peyton Jones | Cc: Edward Kmett; Austin Seipp | Subject: Re: type-checker regression in GHC HEAD? | | Hello Simon, | | ...does that repro-case work for you? shall I create a Trac ticket as | well? I consider this one quite critical for this week's GHC 7.10.1 | RC, if it can't compile `lens` :-/ | | Cheers, | hvr | | On 2014-12-16 at 15:03:49 +0100, Herbert Valerio Riedel wrote: | > On 2014-12-16 at 14:33:00 +0100, Simon Peyton Jones wrote: | >> No immediate bells. | >> | >> Is it possible to reproduce it without compiling all lens's zillion | >> dependencies? | > | > it's actually easier to isolate than expected: | > | > {-# LANGUAGE UndecidableInstances #-} | > | > import Control.Applicative | > import Control.Category | > import Prelude hiding ((.),id) | > | > newtype FocusingPlus w k s a = FocusingPlus { unfocusingPlus :: k | > (s, w) a } | > | > instance Functor (k (s, w)) => Functor (FocusingPlus w k s) where | > fmap f (FocusingPlus as) = FocusingPlus (fmap f as) | > | > instance Applicative (k (s, w)) => Applicative (FocusingPlus w k | s) where | > pure = FocusingPlus . pure | > FocusingPlus kf <*> FocusingPlus ka = FocusingPlus (kf <*> ka) | > | > | > works with GHC 7.8, fails with GHC HEAD w/ | > | > repro.hs:13:25: | > Couldn't match type ‘f0’ with ‘k (s, w)’ | > ‘f0’ is untouchable inside the constraints () bound by the | type signature for pure :: a -> FocusingPlus w k s a at repro.hs:13:3- | 6 | > Expected type: a -> k (s, w) a | > Actual type: a -> f0 a | > Relevant bindings include pure :: a -> FocusingPlus w k s a | (bound at repro.hs:13:3) | > In the second argument of ‘(.)’, namely ‘pure’ | > In the expression: FocusingPlus . pure | > Failed, modules loaded: none. | | -- | "Elegance is not optional" -- Richard O'Keefe

1 0