- ghc-devs - Haskell.org

stack traces when debugging GHC
by Richard Eisenberg 15 Apr '15

15 Apr '15

Hi devs, I've just made a miraculous discovery and I want to share! It has happened many times that I create some bizarre error in GHC and have no clue where it comes from. In the past, I've ended up using pprTrace to label all calls of the failing function, sometimes recursively, until I get an idea of what's going on. This is terribly painful. And then, I noticed that the function Debug.Trace.traceStack (just in the `base` package, not part of GHC) will print out a stack trace, when profiling is enabled. So, I tried building a profiled build of GHC, with -DDEBUG and -fprof-auto (just by editing the "prof" section of build.mk). And then, voila, ASSERTs now print stack traces! And, with a small change in Outputable, I can get pprTrace to print stack traces, too! Hooray! I'd love to put this on the wiki. Any clue where this might be found? Richard

5 5

GHC Weekly News - 2015/04/14
by Austin Seipp 14 Apr '15

14 Apr '15

(You can find a copy of this post online at https://ghc.haskell.org/trac/ghc/blog/weekly20150414) Hi *, It's been a few weeks since the last news bulletin - your editor apologizes about that. It's actually been a relatively slow few weeks here too, and busy-ness outside of GHC has attracted some of my attention. Despite that, GHC 7.10.1 was released, a new HP alpha is out, and things are moving along smoothly. Now that the release is done, things are quitely moving along in `HEAD` - with people committing code with reckless abandon, of course. This week, GHC HQ met up, but it's been very light since the 7.10.1 release. Currently there isn't anything pushing us to do a 7.10.2 release at least for a few more weeks it looks like - but see below. - We puzzled a bit about the release status of 7.10.2, and thought: it's only holding up people who are depending on it. So, who's depending on it, and what do they need fixed? See below for more. - We also talked a bit about performance - it seems the compiler has been getting much slower over time since the 7.8.x release series, and it's time to reign it in. Austin will be spending his week investigating a bit of this, and the causes. == 7.10.2 Status == So, you may be wondering when the 7.10.2 release is. The trick is it happens when you tell us it should happen! So far, taking a look at milestone:7.10.2, we've fixed about half the bugs we currently have marked down to fix. But we're probably going to punt some of those - and we're not sure all the ones that are there should be. So this is a call: **If you need something to be fixed during 7.10.2, please file a ticket, set the milestone, and alert us**. The sooner the better, because it'll inform us as to when we should release. Emailing `ghc-devs@haskell.org` is also a sure-fire way to get our attention. And remember: you can always find out the latest about the next release at the Status page (in this case, for 7.10.2) - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 == Call for help: DocBook to AsciiDoc == The GHC team needs some help. A few months ago, we put out a poll to convert our DocBook-based manual to AsciiDoc. The poll had a mostly lukewarm reception, with the idea that it will A) make life easier for people who frequently modify the users guide, and B) make life easier for people who add things irregularly, as a lower barrier to entry. It looks like we still **want** to do this - but alas, many of us don't have time! So, we're asking the public: Is anyone willing to step up and help here? For example, it may be possible to get a long ways with just `pandoc`, but we need someone to finish it - and in return, we'll help along the way! == List chatter == - Austin Seipp announced GHC 7.10.1. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008700.html - Mark Lentczner announced an alpha Haskell Platform release. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008724.html - David Macek announced MSYS2 packages for GHC on Windows, and also asked for some help with continuous windows building - Windows hackers should help out! https://mail.haskell.org/pipermail/ghc-devs/2015-March/008735.html - Jan Stolarek reports about increased memory usage with GHC 7.10.1. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008751.html - Thomas Miedema chimed into a thread started by Karel Gardas about better parallelizing the GHC build - and hopefully we can get something good out of it. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008749.html - Austin Seipp made a call for help on working on and improving the GHC homepage, and luckily Sergey Bushnyak answered the call and has helped out! https://mail.haskell.org/pipermail/ghc-devs/2015-April/008762.html - Ozgun Ataman kicked off a thread about slower compilation times, with some nasty numbers. It's becoming more clear compiler performance should be a priority for 7.12, and we've let some things slip away from us: https://mail.haskell.org/pipermail/ghc-devs/2015-April/008766.html - A GHC user, Dave, asked the list about some questions with Cross Compilation, as he's attempting to get GHC to work natively inside the Open Embedded build environment. Unfortunately, things haven't been going well so far, and any input from enterprising hackers is appreciated: https://mail.haskell.org/pipermail/ghc-devs/2015-April/008774.html - Dan Aloni has started a discussion about improving GHC's error messages, spurred by a popular blog post he wrote and posted on Reddit about some Happy/GHC improvements he's made. This is a difficult area (error messages in general are hard) to work on, so thanks to Dan for helping! https://mail.haskell.org/pipermail/ghc-devs/2015-April/008778.html - Simon Peyton Jones started a discussion about `GeneralizedNewtypeDeriving` and Safe Haskell, in particular, whatever the current status, our documentation doesn't accurately reflect it! Perhaps someone could help out writing the documentation based on the current status quo? https://mail.haskell.org/pipermail/ghc-devs/2015-April/008783.html - Tamar Christina started a thread about replacing `ghc-split`, an old Perl script inside GHC, but he wanted to know: what do we do about a regex replacement? Mikhail Glushenkov spoke up about a similar decision the LLVM developers used: to use the OpenBSD regex implementation. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008785.html - Alan Zimmerman has posted several questions and threads about the parser and the status of API annotations, which he's been furiously working on now that GHC 7.10 is being used on Hackage. Interested onlookers could learn a thing or two! https://mail.haskell.org/pipermail/ghc-devs/2015-April/008782.html & https://mail.haskell.org/pipermail/ghc-devs/2015-April/008787.html & https://mail.haskell.org/pipermail/ghc-devs/2015-April/008794.html - Gabor Greif has a question about some seemingly strange behavior regarding the interaction between poly-kinded `data` types and overlapping instances. Richard sez: this behavior is expected. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008804.html == Noteworthy commits == - Commit de1160be047790afde4ec76de0a81ba3be0c73fa - refactor the story around switch cases (with a code-size improvement) - Commit 995e8c1c8692b60c907c7d2ccea179d52ca8e69e - drop old `integer-gmp-0.5` source code. - Commit 59f7a7b6091e9c0564f3f370d09398d8c9cd8ad5 - Restore unwind information generation (fixes DWARF generation) - Commit 9f0f99fd41ff82cc223d3b682703e508efb564d2 - Fix an old bug in the demand analyzer (with some nice compiler performance boosts). - Commit a7524eaed33324e2155c47d4a705bef1d70a2b5b - Support for multiple signature files in scope (Backpack). == Closed tickets == #10222, #10219, #8057, #10226, #10220, #9723, #10230, #10208, #10236, #10213, #10231, #10240, #10243, #10237, #10224, #8811, #10197, #10252, #9958, #10253, #8248, #10207, #10214, #9964, #10194, #10251, #10188, #10257, #10247, #10247, #9160, #10259, #9965, #10265, #10264, #10286, #10282, #10290, #10291, #10300, #9929, #8276, #10218, #10148, #10232, #10274, #10275, #10195, and #10233. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 2

Help wanted: working on the GHC webpage
by Austin Seipp 14 Apr '15

14 Apr '15

Hello *, For a while now, I've been wanting to do a facelift on the GHC homepage, but among many other things it's been a low priority. I'd like for people to help, so I've tried to get the ball rolling. The webpages existed in a Darcs repository previously (which wasn't available online), but earlier today I converted them to a git repository which you can find here: https://github.com/haskell-infra/ghc-homepage The site is currently composed of a set of "server side include" files that have a crude form of HTML templating. So it's mostly just pretty verbose to add or refactor anything, and the sites templating and styling is quite old (it dates back at least 10 years!) So, I'm making an official call for some help. At the very least, I'd like to at least end up converting the site to something like Hakyll which is doable without me causing a lot of damage to the stylesheets, but for the actual page itself I'd really appreciate it if anyone could help out! Please send pull requests or file issues, it's much appreciated. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 4

Phabricator as bug tracker system (off topic)
by Andrés Sicard-Ramírez 14 Apr '15

14 Apr '15

Hi, (I apologise for this off topic message) >From the discussion started in https://mail.haskell.org/pipermail/ghc-devs/2014-June/005117.html, it seems GHC HQ didn't choose Phabricator as bug tracker system because migrating from Trac "...There's no real pressure to do so and it would be tons of work". Since Google is shutting down Google Code, we need to move Agda's bug tracker system from Google Code to something else. >From some preliminary investigation, it seems Phabricator bug tracker system (Maniphest) is more robust than GitHub one. I would appreciate some feedback related to Maniphest or other bug tracker system. Thanks, -- Andrés

3 3

GHC Trac down
by Simon Peyton Jones 14 Apr '15

14 Apr '15

Is GHC's Trac down again? It's not working for me. Simon

3 3

Overlapping instances for poly-kinded data
by Gabor Greif 13 Apr '15

13 Apr '15

Hi all, I observe a strange "deriving Show" behaviour for my data type Foo that has proxies: data Foo :: k -> * where Foo :: Proxy t -> Foo t deriving instance Show (Foo t) This works as expected. But now I add instance {-# OVERLAPPING #-} KnownSymbol s => Show (Proxy (s :: Symbol)) where show = ('#' :) . symbolVal instance {-# OVERLAPPING #-} KnownNat n => Show (Proxy (n :: Nat)) where show = ('#' :) . show . natVal these orphan instances, and "deriving Show" won't pick them up. When I go and specialise deriving instance {-# OVERLAPPING #-} KnownNat t => Show (Foo (t :: Nat)) deriving instance {-# OVERLAPPING #-} KnownSymbol s => Show (Foo (s :: Symbol)) then it seems to work allright. Is polykinded derivation so different from the monokinded one? Or is this simply a bug? (a more elaborate WIP example can be found here: https://code.google.com/p/omega/source/browse/mosaic/CloudAtlas.hs?spec=svn…) Cheers, Gabor

3 2

Re: [Haskell-cafe] Generalized Newtype Deriving not allowed in Safe Haskell
by David Feuer 10 Apr '15

10 Apr '15

I think a module exporting some but not all data constructors of a type is fundamentally broken behavior. I would generally be in favor of prohibiting it altogether, and I would be strongly opposed to letting continued support for it break anything else. On Apr 10, 2015 9:05 AM, "Douglas McClean" <douglas.mcclean(a)gmail.com> wrote: > I don't think that 2+3 is equivalent to 2', because an explicit import > list or hiding list could've brought only some of the datatype's > constructors into visibility. > > On Fri, Apr 10, 2015 at 8:07 AM, Richard Eisenberg <eir(a)cis.upenn.edu> > wrote: > >> Here's an idea: For a module to be Safe, then for each exported datatype, >> one of the following must hold: >> 1) The datatype comes with a role annotation. >> 2) The module exports all of the datatype's constructors. >> 3) If the datatype is defined in a place other than the current module, >> the current module exports no fewer data constructors than are exported in >> the datatype's defining module. >> >> Why? >> 1) The role annotation, even if it has no effect, shows that the >> programmer has considered roles. Any mistake here is clearly the >> programmer's fault. >> 2) This datatype is clearly meant not to be abstract. `Coercible` then >> gives clients no more power than they already have. >> 3) This is subtler. It is a common idiom to export a datatype's >> constructors from a package-internal module, but then never to export the >> constructors beyond the package. If such a datatype has a role annotation >> (in its defining module, of course), then we're fine, even if it is >> exported abstractly later. However, suppose we are abstractly re-exporting >> a datatype that exports its constructors from its defining module. If there >> is no role annotation on the datatype, we're in trouble and should fail. >> BUT, if the datatype were exported abstractly in its defining module, then >> we don't need to fail on re-export, because nothing has changed. >> >> >> Actually, we could simplify the conditions. Change (2) to: >> >> 2') The module exports all of the datatype's visible constructors. >> >> I think explaining in terms of separate rules (2) and (3) is a little >> clearer, because the re-export case is slightly subtle, and this subtlety >> can be lost in (2'). >> >> This proposal would require tracking (in interface files, too) whether or >> not a datatype comes with a role annotation. This isn't hard, though. It >> might even help in pretty-printing. >> >> >> An alternative would be to have a way of setting roles differently on >> export than internally. I don't think this breaks the type system, but it's >> yet another thing to specify and support. And we'd have to consider the >> possibility that some module will import a datatype from multiple >> re-exporting modules, each with different ascribed role annotations. Is >> this an error? Does GHC take some sort of least upper bound? I prefer not >> to go here, but there's nothing terribly wrong with this approach. >> >> Richard >> >> On Apr 10, 2015, at 9:37 AM, David Terei <dave.terei(a)gmail.com> wrote: >> >> > I'll prepare a patch for the userguide soon. >> > >> > As for something better, yes I think we can and should. It's on my >> > todo list :) Basically, the new-GND design has all the mechanisms to >> > be safe, but sadly the defaults are rather worrying. Without explicit >> > annotations from the user, module abstractions are broken. This is why >> > we left GND out of Safe Haskell for the moment as it is a subtle and >> > easy mistake to make. >> > >> > If the module contained explicit role annotations then it could be >> > allowed. The discussion in >> > https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that >> > I prefer, such as only exporting the Coerce instance if all the >> > constructors are exported, it seems that the ship sailed on these >> > bigger changes sadly. >> > >> > Cheers, >> > David >> > >> > On 9 April 2015 at 00:56, Simon Peyton Jones <simonpj(a)microsoft.com> >> wrote: >> >> There is a long discussion on >> https://ghc.haskell.org/trac/ghc/ticket/8827 >> >> about whether the new Coercible story makes GND ok for Safe Haskell. >> At a >> >> type-soundness level, definitely yes. But there are other >> less-clear-cut >> >> issues like “breaking abstractions” to consider. The decision on the >> ticket >> >> (comment:36) seems to be: GND stays out of Safe Haskell for now, but >> there >> >> is room for a better proposal. >> >> >> >> >> >> >> >> I don’t have an opinion myself. David Terei and David Mazieres are in >> the >> >> driving seat, but I’m sure they’ll be responsive to user input. >> >> >> >> >> >> >> >> However, I think the user manual may not have kept up with #8827. The >> >> sentence “GeneralizedNewtypeDeriving — It can be used to violate >> constructor >> >> access control, by allowing untrusted code to manipulate protected data >> >> types in ways the data type author did not intend, breaking invariants >> they >> >> have established.” vanished from the 7.8 user manual (links below). >> Maybe >> >> it should be restored. >> >> >> >> >> >> >> >> Safe Haskell aficionados, would you like to offer a patch for the >> manual? >> >> And maybe also a less drastic remedy than omitting GND altogether? >> >> >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> From: Omari Norman [mailto:omari@smileystation.com] >> >> Sent: 09 April 2015 02:44 >> >> To: haskell Cafe >> >> Subject: Generalized Newtype Deriving not allowed in Safe Haskell >> >> >> >> >> >> >> >> When compiling code with Generalized Newtype Deriving and the >> -fwarn-unsafe >> >> flag, I get >> >> >> >> >> >> >> >> -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell >> >> >> >> >> >> >> >> This happens both in GHC 7.8 and GHC 7.10. >> >> >> >> >> >> >> >> I thought I remembered reading somewhere that GNTD is now part of the >> safe >> >> language? The GHC manual used to state that GNTD is not allowed in >> Safe >> >> Haskell: >> >> >> >> >> >> >> >> >> https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell… >> >> >> >> >> >> >> >> But this language on GNTD not being part of the safe language was >> removed in >> >> the 7.8 manual: >> >> >> >> >> >> >> >> >> https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell… >> >> >> >> >> >> >> >> The GHC release notes don't say anything about this one way or the >> other. >> >> Thoughts? >> >> >> >> >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs(a)haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs(a)haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > > -- > J. Douglas McClean > > (781) 561-5540 (cell) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >

1 0

Collapsing HsForAllTy, again
by Alan & Kim Zimmerman 10 Apr '15

10 Apr '15

With the help of Jan Stolarek I tracked down the HsForAllTy flattening to `HsTypes.mk_forall_ty`. This function takes any nested HsForAllTy's where the top one does not have a context defined, and collapses them into a single one. I do not know what the motivation for this is, and if it perhaps speeds up or simplifies further compilation. But now that API Annotations have arrived, making sure we do not lose the annotations for the sub-HsForAllTy causes significant gymnastics in the parser [1]. So my question is, is there a good reason to continue doing this, given the trade-off in parser complexity. Regards Alan [1] https://phabricator.haskell.org/D833

2 7

API Annotations, MINIMAL pragma and BooleanFormula
by Alan & Kim Zimmerman 10 Apr '15

10 Apr '15

My last (known) issue is the MINIMAL pragma for a class definition. In Parser.y this is captured (via `name_boolformula`) as a BooleanFormula (Located RdrName) There is a problem with this from an API annotations point of view in that the constructors (mkBool,mkAnd,mkOr) are smart and try to minimise the boolean formula as it is constructed. Unfortunately this discards information in the process. I see a number of potential solutions a. Capture the original source string for the pragma, and use that for the annotations. This is a bad option. b. Introduce a new variant of BooleanFormula for the AST, and convert to use the current one when evaluating the pragma. c. Keep the BooleanFormula as it is, but do not minimise the formula on construction. I suspect that c is the best option, I do not believe the formulas constructed are particularly complex or numerous, so early optimisation is not necessary. Which is the best option? Or is there a different one? Regards Alan

1 0

RE: Advice on replacing ghc-split
by Tamar Christina 10 Apr '15

10 Apr '15

Thanks Mikhail, I'll read through the threads. Cheers, TamarFrom: Mikhail Glushenkov Sent: ‎09/‎04/‎2015 22:56 To: Tamar Christina Cc: GHC Subject: Re: Advice on replacing ghc-split Hi, On 9 April 2015 at 20:14, Tamar Christina <lonetiger(a)gmail.com> wrote: > [...] > > So I see my options as follows: > > Inline one of the regexp libraries, e.g. pcre-light > [...] When LLVM developers were faced with a similar issue [1], they decided to use OpenBSD's regex implementation [2,3]. [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025047.html [2] http://llvm.org/docs/doxygen/html/regexec_8c_source.html [3] http://llvm.org/docs/doxygen/html/classllvm_1_1Regex.html

1 0