February 2017 - ghc-devs

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

17 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 17 Feb '17

17 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 15 Feb '17

15 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 14 Feb '17

14 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

Improving trac notifications
by Matthew Pickering 13 Feb '17

13 Feb '17

I subscribe to the ghc-tickets[1] mailing list which provides updates to all trac tickets. This is very useful, however when a ticket description is updated the whole description is included in the email which makes it hard to see what actually changed. The web interface shows a nice diff[2] of the changes, I think it would be good if emails could also include a diff rather than the current quite useless output. After a bit of investigation, it appears that the easiest way to achieve this is apply a simple patch to our copy of trac. The current format is hard coded on line 558 in this module, it seems easy to modify this section to instead provide a diff. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.ticket.notification-pys… There is also already a module which has the diff operations implemented which could be used. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.versioncontrol.diff-mod… Another option would be to use something like the `AnnouncerPlugin`[3] but that seems like much more work and would still require someone to write a custom formatter. Any thoughts? Matt [1]: https://mail.haskell.org/mailman/listinfo/ghc-tickets [2]: https://ghc.haskell.org/trac/ghc/ticket/10873?action=diff&version=6 [3]: https://trac-hacks.org/wiki/AnnouncerPlugin

3 8

Trac maintenance
by Ben Gamari 13 Feb '17

13 Feb '17

Hello everyone, I'll be doing some maintenance on the Trac installation in a few minutes. It may be a bit flaky while this happens. Sorry for the inconvenience! Cheers, - Ben

3 5

Nofib runtimes sensitivity to RTS changes
by Joachim Breitner 13 Feb '17

13 Feb '17

Hi, this is mostly a rant, targeted at the very vague fact that runtime performance benchmarks are so damn hard. This commit just came in: https://git.haskell.org/ghc.git/commitdiff/56c9bb39246f9ffd8ed41a0656bfe8e6… Clearly, only parts of the profiling RTS have changed. This is what perf.haskell.org measures: https://perf.haskell.org/ghc/#revision/56c9bb39246f9ffd8ed41a0656bfe8e60d23… Highlights: nofib/time/cryptarithm1 0.502 + 9.36% 0.549 seconds nofib/time/fasta 0.406 + 4.43% 0.424 seconds These changes are permanent, i.e. the following commits consistently give the higher runtimes. But nofib does not even run the profiling RTS! *very audible sigh* (Conclusion: Ignore runtime changes in nofib when the RTS has changed, the results are simply unusable.) I also wonder if we can adjust the input and parameters to nofib (in a new “veryslow” setting) to get them all run in a few seconds on modern hardware, instead of subseconds. 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

2 1

Re: Trac maintenance
by Konrad Gądek 13 Feb '17

13 Feb '17

> upon a quick try, I am missing the live preview of changes as I edit a ticket. > > Oh, and when I try to edit a ticket I get > > AttributeError: 'Environment' object has no attribute 'get_db_cnx' I get the same error when I try to create new ticket. -- Konrad Gądek

2 1