- ghc-devs - Haskell.org

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

Handling of unlifted types
by Erik de Castro Lopo 07 Feb '17

07 Feb '17

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 http://hackage.haskell.org/trac/ghc/browser/includes/rts/storage/InfoTables… 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 http://www.mega-nerd.com/

3 2

Hadrian update
by Andrey Mokhov 06 Feb '17

06 Feb '17

Hello everyone, This is a quick update on the current state of Hadrian, the new build system for GHC (https://github.com/snowleopard/hadrian) Current status ============ We've been slowly but steadily fixing issues, and are getting close to the stage where GHC-devs can start using Hadrian in their everyday development, perhaps at first alongside Make as a fallback option. Here are key remaining issues and what we plan to do about them: * Build rules for distribution and installation are not fully implemented. I don't understand very well the requirements for these build rules and plan to spend some time with Simon Marlow to complete the implementation in March. If anyone can do this earlier, feel free to volunteer, I'm happy to help. * Ability to build stage1 GHC only. This is a quick fix on Hadrian's side but is currently blocked by Shake refactoring. Neil Mitchell is working on this. * Hadrian can't build GHC in the dynamic way. Jose Calderon has bravely taken up the challenge to fix this oldest surviving ticket (#4). There are a lot of other minor issues and continuous refactoring, but I think the above three are most important. If I missed anything, please let me know. How to help ========== 1) One of the simplest way to help the project is to try Hadrian and report any issues you encounter. To try it, clone it into your GHC tree and run it using "hadrian/build.sh" or "hadrian/build.bat", adding "-j --flavour=quickest" to speed things up. See the README for more details: https://github.com/snowleopard/hadrian 2) Whenever you are doing any changes in the GHC that affect the build system, please CC me (@snowleopard) to the corresponding Phab differential. This can save me a lot of time when Hadrian breaks because of changes in GHC. 3) Email me if you have time to write some code or docs for Hadrian - I'll find a good place to start with. Cheers, Andrey

1 0

Phabricator upgrade tomorrow
by Ben Gamari 05 Feb '17

05 Feb '17

Hello everyone! Currently our Phabricator installation is quite old, based on a commit from last July. Given that I have a bit of breathing room now between 8.0.2 and 8.2.1, I'd like to take this opportunity to do an upgrade tomorrow if no one objects. Given that this is the first time I have attempted an upgrade, I expect this may take a few hours in the middle of the day EST. I would expect that the GHC Phabricator instance would be down for much of this time. Let me know if this will cause you undue burden. Cheers, - Ben

2 2

Is there a way to avoid time limit when using travis?
by Takenobu Tani 04 Feb '17

04 Feb '17

Dear devs, Is there a way to avoid time limit when using travis? I started using travis [1]. It is very convenient :) But timeout occurs [2]. The log messages are as follows: =====> InstEqContext2(normal) 1806 of 5700 [0, 0, 0] =====> InstEqContext3(normal) 1807 of 5700 [0, 0, 0] =====> InstContextNorm(normal) 1808 of 5700 [0, 0, 0] The job exceeded the maximum time limit for jobs, and has been terminated. How do you avoid this? Paid plan or something? [1]: https://ghc.haskell.org/trac/ghc/wiki/Travis [2]: https://travis-ci.org/takenobu-hs/ghc/builds/197987055 Regards, Takenobu

3 4