November 2015 - ghc-devs

process library broken on Windows
by Simon Peyton Jones 02 Nov '15

02 Nov '15

I'm getting this on HEAD in te ' libraries\process\System\Process\Internals.hs:106:16: warning: Defined but not used: data constructor 'CGid' Indeed it looks as if CGId(..) should be exported, else createProcess is unusuable. This looks like the right change. Would someone like to check and make the change Simon diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs index 5575ac4..3e23ad5 100644 --- a/System/Process/Internals.hs +++ b/System/Process/Internals.hs @@ -37,6 +37,8 @@ module System.Process.Internals ( #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__) pPrPr_disableITimers, c_execvpe, ignoreSignal, defaultSignal, +#else + CGid(..), GroupID, UserID, #endif withFilePathException, withCEnvironment, translate,

3 8

Better calling conventions for strict functions (bang patterns)?
by Ryan Newton 02 Nov '15

02 Nov '15

Hi all, With module-level Strict and StrictData pragmas coming soon, one obvious question is what kind of the code quality GHC can achieve for strict programs. When it came up in discussion in our research group we realized we didn't actually know whether the bang patterns, `f !x`, on function arguments were enforced by caller or callee. Here's a Gist that shows the compilation of a trivial function: foo :: Maybe Int -> Intfoo !x = case x of Just y -> y https://gist.github.com/rrnewton/1ac722189c65f26fe9ac If that function is compiled to *assume* its input is in WHNF, it should be just as efficient as the isomorphic MLton/OCaml code, right? It only needs to branch on the tag, do a field dereference, and return. But as you can see from the STG and CMM generated, foo *does indeed* enter the thunk, adding an extra indirect jump. Here's the body: c3aY: if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0; c3aZ: // nop R1 = PicBaseReg + foo_closure; call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8; c3b0: I64[Sp - 8] = PicBaseReg + block_c3aO_info; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c3aO; else goto c3aP; c3aP: call (I64[R1])(R1) returns to c3aO, args: 8, res: 8, upd: 8; c3aO: if (R1 & 7 >= 2) goto c3aW; else goto c3aX; c3aW: R1 = P64[R1 + 6] & (-8); Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; c3aX: R1 = PicBaseReg + lvl_r39S_closure; Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; The call inside c3aP is entering "x" as a thunk, which also incurs all of the stack limit check code. I believe that IF the input could be assumed to be in WHNF, everything above the label "c3aO" could be omitted. So... if GHC is going to be a fabulous pure *and* imperative language, and a fabulous lazy *and* strict compiler/runtime.. is there some work we can do here to improve this situation? Would the following make sense: - Put together a benchmark suite of all-strict programs with Strict/StrictData (compare a few benchmark's generated code to MLton, if time allows) - Modify GHC to change calling conventions for bang patterns -- caller enforces WHNF rather than callee. Existing strictness/demand/cardinality analysis would stay the same. Unless there's something I'm really missing here, the result should be that you can have a whole chain of strict function calls, each of which knows its arguments and the arguments it passes to its callees are all in WHNF, without ever generating thunk-entry sequences. Thanks for your time, -Ryan

6 12

Proposal: accept pull requests on GitHub
by Thomas Miedema 02 Nov '15

02 Nov '15

Hello all, my arguments against Phabricator are here: https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator. Some quotes from #ghc to pique your curiosity (there are some 50 more): * "is arc broken today?" * "arc is a frickin' mystery." * "i have a theory that i've managed to create a revision that phab can't handle." * "Diffs just seem to be too expensive to create ... I can't blame contributors for not wanting to do this for every atomic change" * "but seriously, we can't require this for contributing to GHC... the entry barrier is already high enough" GitHub has side-by-side diffs <https://github.com/blog/1884-introducing-split-diffs> nowadays, and Travis-CI can run `./validate --fast` comfortably <https://travis-ci.org/ghc/ghc/builds>. *Proposal: accept pull requests from contributors on https://github.com/ghc/ghc <https://github.com/ghc/ghc>.* Details: * use Travis-CI to validate pull requests. * keep using the Trac issue tracker (contributors are encouraged to put a link to their pull-request in the 'Differential Revisions' field). * keep using the Trac wiki. * in discussions on GitHub, use https://ghc.haskell.org/ticket/1234 to refer to Trac ticket 1234. The shortcut #1234 only works on Trac itself. * keep pushing to git.haskell.org, where the existing Git receive hooks can do their job keeping tabs, trailing whitespace and dangling submodule references out, notify Trac and send emails. Committers close pull-requests manually, just like they do Trac tickets. * keep running Phabricator for as long as necessary. * mention that pull requests are accepted on https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs. My expectation is that the majority of patches will start coming in via pull requests, the number of contributions will go up, commits will be smaller, and there will be more of them per pull request (contributors will be able to put style changes and refactorings into separate commits, without jumping through a bunch of hoops). Reviewers will get many more emails. Other arguments against GitHub are here: https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub. I probably missed a few things, so fire away. Thanks, Thomas

16 20