- ghc-devs - Haskell.org

How do I investigate parser conflicts?
by Jan Stolarek 22 Dec '14

22 Dec '14

I noticed that changes I made to the Parser on my branch increase the number of reduce/reduce conflicts. Are there any tools/techniques/etc I can use to investigate this? Or do I just have to use trial and error (possibly guided with some knowledge of parsing)? Specifically, is there any way I can check which productions are causing conflicts? Janek

3 3

ANN: deepseq-bounded, seqaid, leaky
by Andrew Seniuk 21 Dec '14

21 Dec '14

This trio of related packages explores strictness control in a variety of ways. deepseq-bounded provides classes and generic functions to artificially force evaluation, to extents controlled by static or dynamic configuration. seqaid puts that into practise, providing a GHC plugin to auto-instrument your package with a strictness harness, which is dynamically optimisable during runtime. This is supported directly in the GHC compilation pipeline, without requiring (or performing!) any edits to your sources. leaky is a minimal, prototypic executable that leaks space under current state-of-the-art compilation (GHC 7.8.3 -O2, at the present time). deepseq-bounded hackage: https://hackage.haskell.org/package/deepseq-bounded homepage: http://www.fremissant.net/deepseq-bounded seqaid hackage: https://hackage.haskell.org/package/seqaid homepage: http://www.fremissant.net/seqaid leaky hackage: https://hackage.haskell.org/package/leaky homepage: http://www.fremissant.net/leaky Reddit discussion for the three together: http://www.reddit.com/r/haskell/comments/2ps8f5/ann_deepseqbounded_seqaid_l… Easiest way to try them all, is to install seqaid and run the demo: cabal install seqaid seqaid demo This tests seqaid on a local copy of the leaky source package. It turned out to be routine to extend deepseq-bounded and seqaid to dynamically configurable parallelisation (paraid?). Many other wrappers could be explored, too! Maybe seqaid should be renamed to koolaid or something... It's a pretty complicated system, and just first release, so there's bound to be lots of problems. I've not set up a bug tracker, but will maintain a casual list of bugs and feature requests at http://www.fremissant.net/seqaid/trac and will set up a proper tracker if there's interest. Any isssues (or comments), I'm here, or on the reddit discussion (or email). Andrew Seniuk rasfar on #haskell

1 2

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