- ghc-devs - Haskell.org

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

Improving trac notifications
by Matthew Pickering 12 Feb '17

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

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

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

12 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

Re: [GHC] #12636: ProfHeap's printf modifiers are incorrect
by Siddharth Bhat 11 Feb '17

11 Feb '17

I believe the guarantee at that chunk of code is that void_total of the era will be >= 0. I could add an asset at those sections of code if need be. If not, what is the correct type to be used here? I think size_t is reasonable as none of them are supposed to be negative in the first place. On Sat 11 Feb, 2017, 3:51 PM GHC, <ghc-devs(a)haskell.org> wrote: > #12636: ProfHeap's printf modifiers are incorrect > -------------------------------------+------------------------------------- > Reporter: Phyx- | Owner: bollu > Type: bug | Status: new > Priority: normal | Milestone: > Component: Runtime System | Version: 8.0.1 > Resolution: | Keywords: newcomer > Operating System: Windows | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by Phyx-): > > I actually question the use of `ssize_t` at all for these values. I think > the calculations violate the expected value ranges of `ssize_t` namely > with > > {{{ > censuses[t].void_total += size; > censuses[era].void_total -= size; > }}} > > So I think the types in `_counter` are wrong and have the potential to do > an unsigned underflow as `ssize_t` is only guaranteed to be able to store > values between `[-1, {SSIZE_MAX}]`[1] > > [1] > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12636#comment:5> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler > -- Sending this from my phone, please excuse any typos!

1 0

ghc speed log build script
by Reid Barton 11 Feb '17

11 Feb '17

Hi Joachim, Is the script used to do the builds for perf.haskell.org/ghc/ available somewhere? I couldn't find it poking around your GitHub repositories. I assume from the line "Try to match validate settings" that the build script creates a custom build.mk or similar. I'd like to know exactly what it does so that I can experiment with custom build settings without worrying about them being overridden by your build script. Regards, Reid Barton

2 1