- ghc-devs - Haskell.org

RE: Trac #13255
by Simon Peyton Jones 17 Feb '17

17 Feb '17

I've just rebuilt that branch from scratch. I see Unexpected failures: /tmp/ghctest-q4hnbi/test spaces/./codeGen/should_run/cgrun057.run cgrun057 [bad stderr] (profasm) /tmp/ghctest-q4hnbi/test spaces/./profiling/should_run/T2592.run T2592 [bad stderr] (profasm) /tmp/ghctest-q4hnbi/test spaces/./profiling/should_run/scc001.run scc001 [bad profile] (profasm) (I wish the test suite trimmed off those long paths in the summary...grr) Of these * T2592 is the strange repeated heap-exhaustion thing * scc001 looks like a harmless re-ordering but I don't know why * cgrun057 has this diff -*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: +*** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: I guess harmless. Thanks simon From: Simon Peyton Jones Sent: 17 February 2017 15:12 To: Ben Gamari <ben(a)well-typed.com> Cc: ghc-devs <ghc-devs(a)haskell.org> Subject: Trac #13255 Ben I have pushed a fix for #13255 (blocking the release) to wip/T13255-spj It contains a series of patches, of which the important one is the last. But Phabbing them exceeded my skill level. I'm rebuilding yet again, but I got a couple of strange testsuite errors. Here is one T2592: Heap exhausted; T2592: Current maximum heap size is 1048576 bytes (1 MB). T2592: Use `+RTS -M<size>' to increase it. +T2592: Heap exhausted; +T2592: Current maximum heap size is 1048576 bytes (1 MB). +T2592: Use `+RTS -M<size>' to increase it. Why would the identical message (from the RTS) now be printed twice? I'm baffled. Maybe a clean build will help. Meanwhile I'm out of time. Can I hand the branch off to you to complete and merge? Get back to me if problems. Simon

1 0

Trac #13255
by Simon Peyton Jones 17 Feb '17

17 Feb '17

Ben I have pushed a fix for #13255 (blocking the release) to wip/T13255-spj It contains a series of patches, of which the important one is the last. But Phabbing them exceeded my skill level. I'm rebuilding yet again, but I got a couple of strange testsuite errors. Here is one T2592: Heap exhausted; T2592: Current maximum heap size is 1048576 bytes (1 MB). T2592: Use `+RTS -M<size>' to increase it. +T2592: Heap exhausted; +T2592: Current maximum heap size is 1048576 bytes (1 MB). +T2592: Use `+RTS -M<size>' to increase it. Why would the identical message (from the RTS) now be printed twice? I'm baffled. Maybe a clean build will help. Meanwhile I'm out of time. Can I hand the branch off to you to complete and merge? Get back to me if problems. Simon

2 1

GHC 8.2.1 status
by Ben Gamari 17 Feb '17

17 Feb '17

Hello everyone, It has been a bit over a week since the last update regarding 8.2.1. At the moment we are on the final stretch leading up cutting the branch. Over the last week I have been cleaning up a variety of odds and ends around the tree, bumping core libraries, merging some last patches, smoke testing, and putting the final touches on the Typeable branch which will be merged shortly. However, during testing against Hackage I found a regression (#13255) due to the recent join-points merge that needs to be addressed before we can consider cutting a release candidate. This will likely be resolved soon, which should allow us to release a source release by mid-to-late next week (assuming no further regressions are found). Cheers, - Ben

1 0

Re: Better perf for haddock.base, haddock.Cabal (f4aa998)
by Joachim Breitner 16 Feb '17

16 Feb '17

Hi, Am Donnerstag, den 16.02.2017, 17:46 +0000 schrieb git(a)git.haskell.org: > commit f4aa9984790332a908e8b1321d00a839fb42c3ea > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Thu Feb 16 17:44:58 2017 +0000 > > Better perf for haddock.base, haddock.Cabal > > I think this is due to > commit 6bab649bde653f13c15eba30d5007bef4a9a9d3a > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Thu Feb 16 09:42:32 2017 +0000 > > Improve checking of joins in Core Lint > > Improvement is around 5%. no, https://perf.haskell.org/ghc/#revision/fc9d152b058f21ab03986ea722d0c94688b9… clearly points to this commit: commit fc9d152b058f21ab03986ea722d0c94688b9969f Author: Simon Peyton Jones < simonpj(a)microsoft.com > Date: Thu Feb 16 09:41:55 2017 +0000 Comments and tiny refactor only Which is not just a refactoring. If you look at the diff, e.g. at https://phabricator.haskell.org/rGHCfc9d152b058f21ab03986ea722d0c94688b9969f you will see that after your change, the “one shot arguments according to the environment” are no longer counted towards n_val_args in fun_uds and is_exp. And it seems they should not! Is that something you understand and can explain in a note? I guess https://phabricator.haskell.org/D3089 was merged a bit prematurely in that respect.¹ Greetings, Joachim ¹ There is a workflow problem with Phab’s DR: * A creates a new DR. * B requests changes. DR now in state “revision needed” * C requests changes. DR still in state “revision needed” * A makes changes. DR now in state “needs review” * C looks at the changes and finds his concern addressed and accepts the revision. DR now in state “accepted”. * G comes along, sees a DR in state “accepted” and lands it. Problem: B did not have the chance to check the new revision. -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

3 3

Re: Static data and RULES
by David Feuer 16 Feb '17

16 Feb '17

The vast majority would have no pragma, or at least wouldn't have an unphased NOINLINE pragma, so they would typically inline before demand analysis anyway. David FeuerWell-Typed, LLP -------- Original message --------From: Joachim Breitner <mail(a)joachim-breitner.de> Date: 2/16/17 5:20 PM (GMT-05:00) To: ghc-devs(a)haskell.org Subject: Re: Static data and RULES Hi, Am Donnerstag, den 16.02.2017, 17:12 -0500 schrieb David Feuer: > Strict constructor wrappers will all be allowed to inline after > demand analysis and worker/wrapper. This matches the way we now > handle wrappers actually created in that phase. I am worried that DmdAnal will be less effective the code it sees does not have the wrappers of strict constructors already inlines. It may be that the strictness signature of the wrapper is sufficient to make up for this, but I am not sure. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

FW: [Diffusion] [Build Failed] rGHC6bab649bde65: Improve checking of joins in Core Lint
by Simon Peyton Jones 16 Feb '17

16 Feb '17

perf/haddock.base and haddock.Cabal have improved, hence failure here.. am building with HADDOCK_DOCS on. If someone else gets there first, be my guest From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 16 February 2017 16:08 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHC6bab649bde65: Improve checking of joins in Core Lint Harbormaster failed to build B13964: rGHC6bab649bde65: Improve checking of joins in Core Lint! BRANCHES master USERS simonpj (Author) COMMIT https://phabricator.haskell.org/rGHC6bab649bde65 EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster

1 0

Convincing GHC not to produce unfoldings during simplification
by Ben Gamari 16 Feb '17

16 Feb '17

I'm currently trying to get the interface file bulk imposed by TTypeable down. The branch will currently produce two top-level bindings for each TyCon. For instance, given the type, data Proxy (a :: k) = Proxy the branch will produce (ignoring the promoted datacon for a moment), $tcProxy :: TyCon $tcProxy = GHC.Types.TyCon fpr1 fpr2 -- fingerprints $trModule (GHC.Types.TrNameS "Proxy"#) 1 krep_aebr krep_aebr :: KindRep krep_aebr [InlPrag=NOINLINE CONLIKE] = GHC.Types.KindRepFun (GHC.Types.KindRepVar 0) (GHC.Types.KindRepTYPE GHC.Types.LiftedRep) Note that the KindRep has been marked as NOINLINE; I do this intentionally as these things can grow quite large (consider, for instance, the kind of a promoted tuple constructor). This is especially true as the simplifier tends to float out the constituents of the KindRep. After the first simplifier phase we end up with, krep_sebQ :: GHC.Types.KindRep [LclId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 30 0}] krep_sebQ = GHC.Types.$WKindRepVar (GHC.Types.I# 0#) krep_sebR :: GHC.Types.KindRep [LclId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] krep_sebR = GHC.Types.$WKindRepTYPE GHC.Types.LiftedRep krep_aebr [InlPrag=NOINLINE CONLIKE] :: GHC.Types.KindRep [LclId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] krep_aebr = GHC.Types.KindRepFun krep_sebQ krep_sebR This means that GHC will now include each of the bindings floated out from krep_aebr in the interface file, despite the NOINLINE pragma, as they are all depended upon by the exported $tcProxy through their unfoldings. This is Quite Bad. I have observed that the floated bindings are not included in the interface file with -O0. Moreover, the core2core output clearly shows the unfoldings being added after the first simplifier phase. I haven't yet determined where in the simplifier these unfoldings are being introduced, but if anyone has ideas I'd love to hear them. Cheers, - Ben

2 3

Trac password reset temporarily disabled
by Ben Gamari 15 Feb '17

15 Feb '17

Since the Trac upgrade user password reset and email verification messages have been incorrectly sent to ghc-tickets(a)haskell.org. This appears to be a bug in the AccountManagerPlugin; I have opened a ticket with upstream (https://trac-hacks.org/ticket/13074) and hope to hear back soon. Until this is resolved I have disabled password reset to ensure that no user passwords leak to a public mailing list. If you need your password reset in the meantime please email me privately. Sorry for the inconvenience. Cheers, - Ben

1 0

Extensible records & mandatory/optional record fields
by Harendra Kumar 14 Feb '17

14 Feb '17

In my application, I want some of the fields in a record to have default values while others must always be specified by the user. I can implement this using the rawr records library (http://hackage.haskell.org/package/rawr) like so: def :: ("b" := String) -> R ("a" := Int, "b" := String) def t = (R (#a := 0) :*: R t) -- merge with defaults let r = def (#b := "hello") Here field "a" has a default value (i.e. it is optional when "def" is used) but field "b" does not have a default value and has to be explicitly specified by the user. This is made possible by record merging feature of rawr, making the record extensible. I could not find an equivalent way of achieving this using overloaded records (http://hackage.haskell.org/package/overloaded-records) Is record merging possible or can be made possible using overloaded-records or with the ghc overloaded records poposal? If not, is there a plan to make something like this possible in future? Or will this never be possible with the in built record syntax? Note that, this is handy to simulate mandatory and optional keyword arguments to a function by passing them in the form of a record. Something which is available in other languages like python. -harendra

1 0

Trac
by Simon Peyton Jones 13 Feb '17

13 Feb '17

Trac tickets now open up with the "Modify ticket" boxes open. That makes them vulnerable to accidental edits. Could it be closed by default as it used to be? Simon

5 10