- ghc-devs - Haskell.org

Non-wip/* branches
by Joachim Breitner 10 Feb '17

10 Feb '17

Hi, > facundominguez added a comment. > > @nomeata please, could you remove the branches fd/fix-travis and > fd/fix-travis2? Some server hook is preventing me from doing so. turns out I cannot do that either (which I knew). From experience, I know that I can create, force-push and delete branches of the form wip/*, but can only create and fast-forward-push to branches that are not of this form. This is mostly sensible, but it means that I cannot undo an accidental branch creation outside the wip/* branch. Ben, can you delete the two mentioned branches? And more general, would it make sense to prevent common footfolk like me form creating branches outside the wip/* namespace? This ensures that I can always clean up a mess I make. I can still ask some of the super admins, like you, should I for some reason require a branch outside the wip/* namespace. 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: 8.2.1 Status
by Ryan Scott 10 Feb '17

10 Feb '17

Hi Ben, Sorry for not asking this sooner, but I'd like to merge some form of https://phabricator.haskell.org/D2961 in time for 8.2 if possible. Sadly, doing it "the right way" (according to Simon) is proving to be extremely challenging. A previous iteration of D2961 does work (albeit the code is not as pretty as it ought to be). Are you still planning to cut the 8.2 release tomorrow? If so, I think I'll revert back to the working version of D2961 and merge that, and leave doing it the right way as future work. Ryan S.

2 2

RE: Build time over travis time limit again
by Andrey Mokhov 09 Feb '17

09 Feb '17

Joachim, Ben, I gave it a try on my machine. First of all, we currently need "--flavour=quick" instead of "quickest" because the latter builds only vanilla RTS. If I do: ./build.bat -j --flavour=quick ./build.bat -j --flavour=quick validate Then the testsuite completes, but I get a lot of errors, particularly in "ghci/", "perf/" and "th/". Most of them can probably be fixed relatively easily in Hadrian, but this requires a good understanding of which GHC features these tests actually depend on. I'll create an issue in the Hadrian repo to track down these testsuite failures and will CC you. Cheers, Andrey

3 2

Installation failure building GHC targeting 64-bit Android
by John Ericson 09 Feb '17

09 Feb '17

Hello all, I am working on Nixpkgs support for cross-compiling Haskell. GHC finishes building but fails during installation. As far as I can tell, the error seems to be that `make install` fails after it thinks it has installed haddock, looking for the installed one and not finding it. I've attached a build log and the top-level config.log. In a moment I'll push all relevant Nix expressions in case anyone wants to reproduce exactly. Thanks, John (aka Ericson2314 on GitHub; aka Sonarpulse on Freenode)

1 1

Build time over travis time limit again
by Joachim Breitner 09 Feb '17

09 Feb '17

Hi, in case you are getting failed build reports from Travis and are wondering what’s wrong: Since a few commits our gradually increasing build time seems to have hit the next Travis build time limit (which was already raised to 70 minutes for us). I tried a few obvious knobs, but none of them would help. I will ask for more time from them. But if you know a way to keep build times down, that’d be great. Does Hadrian speed up a build from scratch? 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 1

RE: Build time over travis time limit again
by Andrey Mokhov 08 Feb '17

08 Feb '17

Hi Joachim, > Does Hadrian speed up a build from scratch? Hadrian can build GHC on Windows (AppVeyor) and Linux (Travis) CI instances in about 40 mins using the 'quickest' build flavour (no optimisation/docs). https://ci.appveyor.com/project/snowleopard/hadrian https://travis-ci.org/snowleopard/hadrian On Travis OSX we recently started to time out (jobs are terminated at 48 mins), even though I'm using another trick to save build time on OSX: building with the --integer-simple flag, which skips building the GMP library. Cheers, Andrey

3 2

Re: ghc-devs Digest, Vol 162, Issue 13
by Demi Obenour 08 Feb '17

08 Feb '17

What if the function is strict? If the function is strict, then no think is required. Indeed, I see unsafe casts from unlifted to lifted types in at least two places in GHC (the bytecode linker and code related to hs_put_mvar). The only absolute limitation is GC, which doesn't care either way. One caveat is that such a function CANNOT be called as if it wasn't levity-polymorphic, because of precisely the issue you mentioned — the caller, not the callee, is responsible for evaluating the arguments. So this would need extensions to the kind system, as well as special handling in the compiler. On Feb 7, 2017 7:20 AM, <ghc-devs-request(a)haskell.org> wrote: > Send ghc-devs mailing list submissions to > ghc-devs(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > or, via email, send a message with subject or body 'help' to > ghc-devs-request(a)haskell.org > > You can reach the person managing the list at > ghc-devs-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ghc-devs digest..." > > > Today's Topics: > > 1. RE: Handling of unlifted types (Simon Peyton Jones) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 7 Feb 2017 11:18:09 +0000 > From: Simon Peyton Jones <simonpj(a)microsoft.com> > To: Erik de Castro Lopo <mle+hs(a)mega-nerd.com>, "ghc-devs(a)haskell.org" > <ghc-devs(a)haskell.org> > Subject: RE: Handling of unlifted types > Message-ID: > <DM2PR21MB002861CF4C24D71601C32B45AD430@DM2PR21MB0028. > namprd21.prod.outlook.com> > > Content-Type: text/plain; charset="utf-8" > > Suppose > > f1 :: forall (a :: TYPE LiftedPtrRep). a -> Closure > f2 :: forall (a :: TYPE UnliftedPtrRep). a -> Closure > f3 :: forall (a :: TYPE FloatRep). a -> Closure > > f3 takes its argument in a floating point register, whereas f1 and f2 take > their arguments in a pointer register; so you can't have a function > polymorphic in all three. See the paper (have you read it?) > > You might think that f1 and f2 are more compatible, since they both take a > pointer, but consider the call > f1 (g x) > f2 (h x) > > For f1 we'll build a thunk for (g x) and pass it to f1. For f2 we'll > evaluate (h x) and pass the result to f2. So the calls are different. > > In short, there is a good reason that we can't be polymorphic here. You'll > have to use three different functions. > > Simon > > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Erik > de > | Castro Lopo > | Sent: 05 February 2017 08:49 > | To: ghc-devs(a)haskell.org > | Subject: Handling of unlifted types > | > | Hi all, > | > | I'm working on pulling the core parts of Joachim Breitner's > ghc-heap-view > | library into GHC. The WIP Phab review is here: > | > | https://phabricator.haskell.org/D3055 > | > | Currently that library has a function: > | > | getClosureData :: a -> IO Closure > | > | which works fine for lifted types. However, some of the supported > closure > | types in > | > | > | https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fhackage.hask > | ell.org%2Ftrac%2Fghc%2Fbrowser%2Fincludes%2Frts% > 2Fstorage%2FInfoTables.h&dat > | a=02%7C01%7Csimonpj%40microsoft.com%7Ca5585e761d5149d4f3c608d44da3 > f3dc%7C72f > | 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636218813965987006& > sdata=5ze3nbAjXYm > | Ey7H6M4Imtyz7dVH1bjEtloUJWQ2ItWo%3D&reserved=0 > | > | actually refer to unlifted types, like the `MUT_ARR_PTRS_*` and > | `SMALL_MUT_ARR_PTRS_*`. > | > | I've had a look at the levity polymorphism stuff implemented in ghc 8.0 > and > | came up with a new type for `getClosureData`: > | > | getClosureData :: forall (r :: RuntimeRep) (a :: TYPE r). a -> IO > | Closure > | > | but that results in: > | > | A representation-polymorphic type is not allowed here: > | Type: a > | Kind: TYPE r > | In the type of binder ‘x’ > | > | Am I barking up the wrong tree here? Any one have a clue on how I might > make > | progress on this? > | > | > | Erik > | -- > | ---------------------------------------------------------------------- > | Erik de Castro Lopo > | https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fwww.mega- > | nerd.com%2F&data=02%7C01%7Csimonpj%40microsoft.com% > 7Ca5585e761d5149d4f3c608d > | 44da3f3dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > 7C636218813965987006&sd > | ata=M8bvL%2BDEFYX7Sx%2FAipnRDBBtbFBMcAl7p3Rf86Hbe%2FA%3D&reserved=0 > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs(a)haskell.org > | https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fmail.haskell > | .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=02%7C01%7Csimonpj%40microsoft.com% > 7Ca5585e761d5149d4f3c608d44da3f3 > | dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > 7C636218813965987006&sdata=9AQ > | mgEerIRrUeT%2BBRrGriMiAm2oJ7F9mQrMrBAPCQq0%3D&reserved=0 > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > ------------------------------ > > End of ghc-devs Digest, Vol 162, Issue 13 > ***************************************** >

1 0

8.2.1 Status
by Ben Gamari 08 Feb '17

08 Feb '17

Hello everyone, Over the last week I've been busily helping Richard finish up the last bits destined for 8.2.1. At this point things are looking okay, although there is still a bit of a push necessary before we can cut an 8.2 branch, * We have decided to punt the separation of * and Constraint (#11715) off to 8.4 due to design complications * The generalization of (->)'s kind (D2038) is done and passes the testsuite save a performance regression which I am currently investigating * The recent levity polymorphism work regressed the profiled build (#13223) which I am working on fixing. * The type-indexed Typeable patch works save one regression which I am working on with Simon * Merge the subset of OverloadedRecordFields wanted for 8.2 * Update boot library submodules It looks likely that these tasks will require a majority of the rest of this week to work out. Consequently, I'm currently aiming to cut the branch for 8.2 on Friday. I'll then spend a few days testing the tree against Hackage and, if nothing goes terribly awry, likely cut a source release mid-to-late next week. Cheers, - Ben

2 2

RE: [Diffusion] [Build Failed] rGHCb8f58d79ee3e: Another improvement to SetLevels
by Simon Peyton Jones 07 Feb '17

07 Feb '17

https://phabricator.haskell.org/harbormaster/build/20383/ There's something very odd here. I got "stat too good" solidly, so I reduced the number. But Harbormaster consistently allocates more 6.6% more than my 64-bit machine. I have no idea why. I reported this some days ago. It only seems to happen on this test. Anyway, I have to go home, but I suppose that we can "solve" this by giving it a wider bound. Feel free to do that. Or center it on what Harbormaster says, and I'll get used to filtering out that failure from my own builds. sorry to leave this loose end. It's annoying Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 07 February 2017 17:11 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHCb8f58d79ee3e: Another improvement to SetLevels Harbormaster failed to build B13774: rGHCb8f58d79ee3e: Another improvement to SetLevels! BRANCHES master USERS simonpj (Author) COMMIT https://phabricator.haskell.org/rGHCb8f58d79ee3e EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster

1 0

D2903 Needs Review
by Thomas Jakway 07 Feb '17

07 Feb '17

If anyone has a free moment I'd appreciate feedback on D2903: https://phabricator.haskell.org/D2903 -Thomas

2 1