- ghc-devs - Haskell.org

Thanks to Reid and Thomas
by Simon Peyton Jones 07 Sep '15

07 Sep '15

Thomas, Reid, As I get back from ICFP, I’d like to take the opportunity to thank you for huge amount of work that you two personally have put into GHC recently. Your interventions are always thoughtful, supportive, and on target. GHC is a huge project, and lots of people contribute to it. I am truly grateful to all of them. But you two have been particularly active in the last year and I wanted to say thank you. Onward and upward, Simon

3 3

Proposal: Argument Do
by Andrew Gibiansky 05 Sep '15

05 Sep '15

Trac: https://ghc.haskell.org/trac/ghc/ticket/10843 I would like the following to be valid Haskell code: main = when True do putStrLn "Hello!" Instead of requiring a dollar sign before the "do". This would parse as main = when True (do putStrLn "Hello!") Has this been tried before? It seems fairly simple -- is there some complexity I'm missing? I've always been confused as to why the parser requires `$` there, and I've heard a lot of others ask about this as well. Perhaps we could fix that? PS. Regardless of whether this goes anywhere, it was fun to learn how to hack on GHC. It was surprisingly easy; I wrote up my experience here <http://rawgit.com/gibiansky/4c54f767bf21a6954b23/raw/67c62c5555f40c6fb67b12…>. The GHC wiki is outstanding; pretty much every intro question about ghc development I had was answered on a fairly easy-to-find wiki age. (Except for some stuff related to generating documentation and docbook, but whatever.)

2 3

A process for reporting security-sensitive issues
by Michael Smith 04 Sep '15

04 Sep '15

I feel there should be some process for reporting security-sensitive issues in GHC -- for example, #9562 and #10826 in Trac. Perhaps something like the SensitiveTicketsPlugin [3] could be used? [1] https://ghc.haskell.org/trac/ghc/ticket/9562 [2] https://ghc.haskell.org/trac/ghc/ticket/10826 [3] https://trac-hacks.org/wiki/SensitiveTicketsPlugin

3 2

Foreign calls and periodic alarm signals
by Phil Ruffwind 04 Sep '15

04 Sep '15

TL;DR: Does 'foreign import safe' silence the periodic alarm signals? I received a report on this rather strange bug in 'directory': https://github.com/haskell/directory/issues/35#issuecomment-136890912 I've concluded based on the dtruss log that it's caused by the timer signal that the GHC runtime emits. Somewhere inside the guts of 'realpath' on Mac OS X, there is a function that does the moral equivalent of: while (statfs64(…) && errno == EINTR); On a slow filesystem like SSHFS, this can cause a permanent hang from the barrage of signals. The reporter found that using 'foreign import safe' mitigates the issue. What I'm curious mainly is that: is something that the GHC runtime guarantees -- is using 'foreign import safe' assured to turn off the periodic signals for that thread? I tried reading this article [1], which seems to be the only documentation I could find about this, and it didn't really go into much depth about them. (I also couldn't find any info about how frequently they occur, on which threads they occur, or which specific signal it uses.) I'm also concerned whether there are other foreign functions out in the wild that could suffer the same bug, but remain hidden because they normally complete before the next alarm signal. [1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals

2 2

Re: [Diffusion] [Committed] rGHCbe0ce8718ea4: Fix for crash in setnumcapabilities001
by Thomas Miedema 04 Sep '15

04 Sep '15

Simon, for what it's worth, I sporadically (< once per month) see this test timing out on Phabricator. Latest occurence: https://phabricator.haskell.org/harbormaster/build/5904/?l=0 Thomas On Fri, Jun 26, 2015 at 10:32 AM, simonmar (Simon Marlow) < noreply(a)phabricator.haskell.org> wrote: > simonmar committed rGHCbe0ce8718ea4: Fix for crash in > setnumcapabilities001 (authored by simonmar). > > Fix for crash in setnumcapabilities001 > > getNewNursery() was unconditionally incrementing next_nursery, which > is normally fine but it broke an assumption in > storageAddCapabilities(). This manifested as an occasional crash in > the setnumcapabilities001 test. >

1 0

Fwd: RE: D1182: Implement improved error messages for ambiguous type variables (#10733)
by Edward Z. Yang 03 Sep '15

03 Sep '15

It's certainly true that hsig is in flux, but it doesn't seem like injective type families should have broken this test. I'll take a look. Edward Excerpts from Simon Peyton Jones's message of 2015-09-03 09:08:23 -0700: > Edward > > | Jan's injective type families commit is causing tcfail220 to fail, but > | that's unrelated to this ticket. > > This is true. I told Jan to commit anyway because tcfail220 is a "hsig" test, and > a) I know that hsigs are in flux (although I am not clear about how) > b) I don't understand them enough to fix. > > So I hope it's ok to have broken this. Jan and I can certainly help when you want to fix it. > > Meanwhile would you mark it as expect-broken. (Although I am not sure that it's worth opening a fresh ticket for it.) > > thanks > > Simon > > | -----Original Message----- > | From: noreply(a)phabricator.haskell.org > | [mailto:noreply@phabricator.haskell.org] > | Sent: 03 September 2015 07:11 > | To: Simon Peyton Jones > | Subject: [Differential] [Commented On] D1182: Implement improved error > | messages for ambiguous type variables (#10733) > | > | KaneTW added a comment. > | > | Jan's injective type families commit is causing tcfail220 to fail, but > | that's unrelated to this ticket. > | > | > | REPOSITORY > | rGHC Glasgow Haskell Compiler > | > | REVISION DETAIL > | https://phabricator.haskell.org/D1182 > | > | EMAIL PREFERENCES > | https://phabricator.haskell.org/settings/panel/emailpreferences/ > | > | To: KaneTW, simonpj, bgamari, austin > | Cc: goldfire, simonpj, thomie --- End forwarded message ---

2 2

addTopDecls restrictions
by Richard Eisenberg 03 Sep '15

03 Sep '15

Hi Geoff, The TH addTopDecls function is restricted to only a few kinds of declarations (functions, mostly). This set has been expanded in #10486 (https://ghc.haskell.org/trac/ghc/ticket/10486) Do you remember why the set of allowed declarations is restricted? It looks to me like any declaration would be OK. Thanks! Richard

1 0

HEADS UP: interface file format change, full rebuild required
by Jan Stolarek 03 Sep '15

03 Sep '15

I just pushed injective type families patch, which changes interface file format. Full rebuild of GHC is required after you pull. Jan

2 1

Re: [Haskell-cafe] Foreign calls and periodic alarm signals
by Brandon Allbery 03 Sep '15

03 Sep '15

On Wed, Sep 2, 2015 at 7:56 PM, Donn Cave <donn(a)avvanta.com> wrote: > Sure are, though I don't know of any that have been identified so > directly as yours. I mean it sounds like you know where and how it's > breaking. Usually we just know something's dying on an interrupt and > then think to try turning off the signal barrage. It's interesting > that you're getting a stall instead, due to an EINTR loop. > network is moderately infamous for (formerly?) using unsafe calls that block.... -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Testsuite and validate changes
by Thomas Miedema 02 Sep '15

02 Sep '15

All, I made the following changes today: * `make accept` now runs all tests for a single way (instead of all ways) * `make test` now runs all tests for a single way (instead of all ways) * `./validate` now runs all tests for a single way (instead of skipping some tests) * Phabricator now runs all tests for a single way (instead of skipping some tests) You can run `make slowtest` in the root directory, or `make slow` in the testsuite directory, to get the old behavior of `make test` back. More information: * https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#Speedse… * https://phabricator.haskell.org/D1178 * Note [validate and testsuite speed] in the toplevel Makefile Thanks, Thomas

1 0