- ghc-devs - Haskell.org

Perl for Windows and GHC
by Gintautas Miliauskas 21 Dec '14

21 Dec '14

Hi, apologies again about disappearing completely. I started a new job recently and have been flying all over the place. I'm happy to see that D339 (auto-download mingw, upgrade version of gcc) has been merged, but there is an issue that needs followup. Austin mentioned that we need a Perl distribution for a proper GHC runtime. This is not a problem while running in msys2, since msys provides a perl binary, but this makes packaging a self-sufficient GHC distribution harder, AFAIU. Can we punt on this and let the Haskell Platform folks figure out how to package Perl properly (that's the only context where it's necessary, right?), or is this an urgent issue? If the latter, should we roll back D339 until it's resolved? If we really need to package perl, the PortableZIP edition of Strawberry Perl <http://strawberryperl.com/releases.html> should work, I think. It's on the heavy side (92MB) and would probably need to be trimmed beforehand though. Are there any utilities other than ghc-split which rely on perl at ghc runtime? If not, are there any plans to convert ghc-split to a sane language? I would sign up if I knew I would have the time... :( -- Gintautas Miliauskas

2 1

GHC Heap Profiler time axis
by Anton Dessiatov 19 Dec '14

19 Dec '14

Hello, GHC hackers! Reposting this message from haskell-café, because it seems like this mailing list is closer to the subject. For the last 2 days I’m debugging something that looks like a space leak. My program is a rather long-running network service. When I first used heap profiler I was a bit confused with its output that showed that my program was running for only about 0.3-0.4 seconds when I launched it idling for about a minute. That was confusing enough for me to dig into GHC sources trying to figure out the reason behind this and I found that values of the sample times are taken from the mut_user_time function, which returns a time that process spent in user-mode code (outside the kernel) minus time spent on garbage collection. This introduces great amount of unpredictable non-linearity of the heap profile graph x axis, which I personally consider very counterintuitive. So my question is does anybody know why is it done this way? Wouldn’t it be better if x axis would just show a time elapsed since the process started? Kind regards, Anton.

1 0

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