From ben at well-typed.com Tue Aug 1 02:19:06 2017 From: ben at well-typed.com (Ben Gamari) Date: Mon, 31 Jul 2017 22:19:06 -0400 Subject: GHC release timing and future build infrastructure Message-ID: <8760e8m3mt.fsf@ben-laptop.smart-cactus.org> Hello everyone, I just posted a pair of posts on the GHC blog [1,2] laying out some thoughts on the GHC release cycle timing [1] and how this relates to the in-progress Jenkins build infrastructure [2]. When you have a some time feel free to give them a read and comment (either here or on the Reddit thread [3]). Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule [2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci [3] https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_ghcs_release_schedule/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From harendra.kumar at gmail.com Tue Aug 1 09:45:31 2017 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 1 Aug 2017 15:15:31 +0530 Subject: GHC 8.2 generated code faster than 8.0 but slower than 7.10 Message-ID: Unicode normalization library ( https://github.com/harendra-kumar/unicode-transforms) shows around 10% improvement with GHC 8.2.1 when compared to GHC 8.0.1, across most benchmarks. However, it is still somewhat slower when compared to GHC 7.10.3. Here are some results: GHC 7.10.3: benchmarking unicode-transforms-text/NFD/English time 4.823 ms (4.765 ms .. 4.902 ms) benchmarking unicode-transforms-text/NFD/Devanagari time 16.46 ms (16.24 ms .. 16.78 ms) GHC 8.0.1 benchmarking unicode-transforms-text/NFD/English time 6.330 ms (6.232 ms .. 6.439 ms) benchmarking unicode-transforms-text/NFD/Devanagari time 18.02 ms (17.77 ms .. 18.22 ms) GHC 8.2.1 benchmarking unicode-transforms-text/NFD/English time 5.659 ms (5.594 ms .. 5.740 ms) benchmarking unicode-transforms-text/NFD/Devanagari time 16.48 ms (16.30 ms .. 16.69 ms) This library has been optimized with an objective to match or better (in some cases it is better) the performance of the equivalent ICU C++ library (compare only decompose normalization). Some of the last hurdles to match the best case of C++ were in the code generated by GHC. Also, for GHC 7.10 LLVM generated code is significantly faster than GHC native, I have not yet tested LLVM backend with 8.2.1 so not sure if that too has improved correspondingly. I just wanted to share these results with the GHC devs. Thanks for all the good work. Also wondering which specific changes might have caused this improvement. Thanks, Harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Aug 1 10:12:03 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 1 Aug 2017 10:12:03 +0000 Subject: GHC 8.2 generated code faster than 8.0 but slower than 7.10 In-Reply-To: References: Message-ID: Thanks. Could you open a Trac ticket, and explain carefully how to reproduce your results? Surely 8.4 should be faster than 7.10! Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Harendra Kumar Sent: 01 August 2017 10:46 To: ghc-devs at haskell.org Subject: GHC 8.2 generated code faster than 8.0 but slower than 7.10 Unicode normalization library (https://github.com/harendra-kumar/unicode-transforms) shows around 10% improvement with GHC 8.2.1 when compared to GHC 8.0.1, across most benchmarks. However, it is still somewhat slower when compared to GHC 7.10.3. Here are some results: GHC 7.10.3: benchmarking unicode-transforms-text/NFD/English time 4.823 ms (4.765 ms .. 4.902 ms) benchmarking unicode-transforms-text/NFD/Devanagari time 16.46 ms (16.24 ms .. 16.78 ms) GHC 8.0.1 benchmarking unicode-transforms-text/NFD/English time 6.330 ms (6.232 ms .. 6.439 ms) benchmarking unicode-transforms-text/NFD/Devanagari time 18.02 ms (17.77 ms .. 18.22 ms) GHC 8.2.1 benchmarking unicode-transforms-text/NFD/English time 5.659 ms (5.594 ms .. 5.740 ms) benchmarking unicode-transforms-text/NFD/Devanagari time 16.48 ms (16.30 ms .. 16.69 ms) This library has been optimized with an objective to match or better (in some cases it is better) the performance of the equivalent ICU C++ library (compare only decompose normalization). Some of the last hurdles to match the best case of C++ were in the code generated by GHC. Also, for GHC 7.10 LLVM generated code is significantly faster than GHC native, I have not yet tested LLVM backend with 8.2.1 so not sure if that too has improved correspondingly. I just wanted to share these results with the GHC devs. Thanks for all the good work. Also wondering which specific changes might have caused this improvement. Thanks, Harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Tue Aug 1 12:21:36 2017 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 1 Aug 2017 17:51:36 +0530 Subject: GHC 8.2 generated code faster than 8.0 but slower than 7.10 In-Reply-To: References: Message-ID: https://ghc.haskell.org/trac/ghc/ticket/14072 8.2.1 is (marginally) better than 7.8.4 on this benchmark, so I guess 8.4 can be better than 7.10.3. -harendra On 1 August 2017 at 15:42, Simon Peyton Jones wrote: > Thanks. Could you open a Trac ticket, and explain carefully how to > reproduce your results? > > > > Surely 8.4 should be faster than 7.10! > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Harendra > Kumar > *Sent:* 01 August 2017 10:46 > *To:* ghc-devs at haskell.org > *Subject:* GHC 8.2 generated code faster than 8.0 but slower than 7.10 > > > > Unicode normalization library (https://github.com/harendra- > kumar/unicode-transforms > ) > shows around 10% improvement with GHC 8.2.1 when compared to GHC 8.0.1, > across most benchmarks. However, it is still somewhat slower when compared > to GHC 7.10.3. Here are some results: > > > > GHC 7.10.3: > > benchmarking unicode-transforms-text/NFD/English > time 4.823 ms (4.765 ms .. 4.902 ms) > > benchmarking unicode-transforms-text/NFD/Devanagari > time 16.46 ms (16.24 ms .. 16.78 ms) > > > GHC 8.0.1 > > > benchmarking unicode-transforms-text/NFD/English > time 6.330 ms (6.232 ms .. 6.439 ms) > > benchmarking unicode-transforms-text/NFD/Devanagari > time 18.02 ms (17.77 ms .. 18.22 ms) > > GHC 8.2.1 > > > benchmarking unicode-transforms-text/NFD/English > time 5.659 ms (5.594 ms .. 5.740 ms) > > benchmarking unicode-transforms-text/NFD/Devanagari > time 16.48 ms (16.30 ms .. 16.69 ms) > > > > This library has been optimized with an objective to match or better (in > some cases it is better) the performance of the equivalent ICU C++ library > (compare only decompose normalization). Some of the last hurdles to match > the best case of C++ were in the code generated by GHC. Also, for GHC 7.10 > LLVM generated code is significantly faster than GHC native, I have not yet > tested LLVM backend with 8.2.1 so not sure if that too has improved > correspondingly. > > > > I just wanted to share these results with the GHC devs. Thanks for all the > good work. Also wondering which specific changes might have caused this > improvement. > > > > Thanks, > > Harendra > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at ara.io Tue Aug 1 13:05:31 2017 From: me at ara.io (Ara Adkins) Date: Tue, 1 Aug 2017 14:05:31 +0100 Subject: GHC release timing and future build infrastructure Message-ID: Heya, I very much agree with the thoughts on the variability of the release cadence. The following is somewhat of a stream of consciousness as I read, so please excuse any lack of coherence. When you talk about the bugs being significant blockers to the latest release I feel like that kind of issue isn't necessarily touched by moving to a shorter release cadence. In fact if we're unwilling to let certain fixes wait a release then it exacerbates the risk of slowing down a release. I'm not really sure what to do about this, other than adopting the mentality that fixes might not make the major release and will have to come in a point upgrade if they can't be merged to the release branch in time. Regarding the benefits of an abbreviated release cycle, we see it quite a lot in the rust community. There's a good amount of community involvement with the new releases, and new features are hotly anticipated as they often occur on a timescale where the enthusiasm is still there. I also feel, though this is purely anecdotal, that the more agile release schedule encourages community contributions as the tangible benefits of contributor work can be realised much more quickly. The number of RFCs in discussion at the moment is evidence of that, I feel. It's not all sunny, however, as having so many rapid releases means that it's sometimes difficult to rally the community around certain releases and feature sets. This is perhaps less of an issue due to the maturity of GHC and its ecosystem, but, like you say, it's important to find a good trade-off between release cadence and stability. Personally, I think Rust's cadence is a touch too short. On a related note, there's a 'checkpoints' initiative to build rallying releases that represent significant milestones in development [1]. This is, however, also tied into Rust's stability story, so only parts of it are relevant to GHC. In terms of automated tooling, I think there is significant benefit from it. Again, using rust as an example, there is cargobomb [2], a significant automated testing initiative that both combines packages on Cargo, and runs their test suites. I feel that a combination of the Stackage LTS and Nightly releases would provide a well-curated subset of Hackage that could possibly be used in a similar fashion. This hits on your item (b). Regarding your questions: - In comparison to rust it can feel like there's significant delay in being able to really use GHC's newest features. I feel like this delay can hinder adoption of the features as much of the enthusiasm for them has died down by the time they're properly available. - With the advent of tools such as `stack`, the compiler upgrade process has almost become trivial. While not everyone uses it, it requires no more work than upgrading to a new LTS release and running `stack setup`. Nevertheless, I could imagine four upgrades a year still being okay if it was manual. - The three release policy is an interesting case as the question of changing it really comes down to how we view the GHC stability story. Personally, I think we want to target a time-period of stability, rather than a number of releases. Whether that time period is 1.5 years (assuming a six-month release cadence), or 3 years (rounding the current release cadence) seems like a totally independent discussion to me. - I think I've covered incentives to contribute in my discussion of Rust above. I hope that's useful! Best, _ara [1] https://github.com/rust-lang/rfcs/pull/2052 [2] https://github.com/rust-lang-nursery/cargobomb > On 1 Aug 2017, at 03:19, Ben Gamari wrote: > > > Hello everyone, > > I just posted a pair of posts on the GHC blog [1,2] laying out some > thoughts on the GHC release cycle timing [1] and how this relates to the > in-progress Jenkins build infrastructure [2]. When you have a some time > feel free to give them a read and comment (either here or on the Reddit > thread [3]). > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule > [2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci > [3] https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_ghcs_release_schedule/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.terepeta at gmail.com Tue Aug 1 13:37:06 2017 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Tue, 01 Aug 2017 13:37:06 +0000 Subject: New primitive types? Message-ID: Hi all, I'm working on making it possible to pack constructor fields [1], example: ``` data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Int32 ``` should only require 4 bytes for unpacked `Float` and 4 bytes for unpacked `Int32`, which on 64-bit arch would take just 1 word (instead of 2 it currently does). The diff to support packing of fields is in review [2], but to really take advantage of it I think we need to introduce new primitive types: - Int{8,16,32}# - Word{8,16,32}# along with some corresponding primops and with some other follow-up changes like extending `PrimRep`. Then we could use them in definitions of `Int{8,16,32}` and `Word{8,16,32}` (they're currently just wrapping `Int#` and `Word#`). Does that sound ok with everyone? (just making sure that this makes sense before I invest more time into this :) Thanks, Michal [1] https://ghc.haskell.org/trac/ghc/ticket/13825 [2] https://phabricator.haskell.org/D3809 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Tue Aug 1 15:02:12 2017 From: ggreif at gmail.com (Gabor Greif) Date: Tue, 1 Aug 2017 17:02:12 +0200 Subject: Occurrence info on binders and STG Message-ID: Hi devs! I just had a short exchange with Joachim, he sent me to this place. Can anybody explain how occurrence info is used in STG? Cheers and thanks, Gabor ---------- Forwarded message ---------- From: Joachim Breitner Date: Tue, 01 Aug 2017 10:47:48 -0400 Subject: Re: [commit: ghc] master: Simplify OccurAnal.tagRecBinders (b311096) To: Gabor Greif Hi, feel free to CC the mailing list on such questions. I often don’t know things perfectly either. Am Dienstag, den 01.08.2017, 16:43 +0200 schrieb Gabor Greif: > > Loosely related question: Very loosely :-) > - when doing STG Cse, the occurrence info is not updated when a > wild(card)-binder is used. Is there a recommended way to re-run > occ-analysis on STG? (I fear there is not.) I fear that too. It the occ info used past that stage? > - I noticed that "wild"-binders sometimes do not appear at their > binding site (after "of" and "{") in STG dumps. Dumping gets > suppressed when they are deemed dead. Should STG consider occ-info at > all? Good questions. I remember that Simon commented on that before, but I don’t remember where… > oachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org From mail at joachim-breitner.de Tue Aug 1 15:24:51 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 01 Aug 2017 11:24:51 -0400 Subject: code layout of cryptarithm1 Message-ID: <1501601091.1258.8.camel@joachim-breitner.de> Hi, if you look at https://perf.haskell.org/ghc/#graph/nofib/time/cryptarithm1 you see that it’s performance varies a lot, sometimes by 10%, between commits should have nothing to do with performance. But most (not all!) of the commits where the performance changes affect the runtime in some way. I conclude that there is something about the code layout that makes this program run faster or slower. If anyone here enjoys tracing and understanding such low-level issues: Here is a nice target to aim at. (I don’t… but I’d appreciate less noise from gipeda :-)) Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From allbery.b at gmail.com Tue Aug 1 16:30:17 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 1 Aug 2017 12:30:17 -0400 Subject: GHC release timing and future build infrastructure In-Reply-To: <8760e8m3mt.fsf@ben-laptop.smart-cactus.org> References: <8760e8m3mt.fsf@ben-laptop.smart-cactus.org> Message-ID: On Mon, Jul 31, 2017 at 10:19 PM, Ben Gamari wrote: > I just posted a pair of posts on the GHC blog [1,2] laying out some > thoughts on the GHC release cycle timing [1] and how this relates to the > in-progress Jenkins build infrastructure [2]. When you have a some time > feel free to give them a read and comment (either here or on the Reddit > thread [3]). > This release was actually a bit unusual for recent releases, in that a significant delay did *not* come from working around a major breaking behavior change in a Tier 1 platform; recent examples being macOS's load commands limit and Ubuntu defaulting to position-independent executables. I think this might be relevant to the question of slipping extra stuff into releases: it's become so common to have extra time courtesy of Tier 1 platforms breaking things on us that slipping extra stuff in is now expected. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Aug 1 18:07:49 2017 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 01 Aug 2017 18:07:49 +0000 Subject: New primitive types? In-Reply-To: References: Message-ID: One issue with packed fields is that on many architectures you can't quite do subword reads or writes. So it might not always be a win. There's also the issue that c-- as it exists in ghc doesn't have any notion of subword sized types. That said, I do support making word/int64/32 # types more first class / built in. (I hit some issues which tie into this topic in the process of working on my still in progress safeword package. ) Point being: I support improving what we have, but it's got a bit of surface area. Please let me know how I can help you dig into this though On Tue, Aug 1, 2017 at 9:37 AM Michal Terepeta wrote: > Hi all, > > I'm working on making it possible to pack constructor fields [1], > example: > > ``` > data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Int32 > ``` > > should only require 4 bytes for unpacked `Float` and 4 bytes for > unpacked `Int32`, which on 64-bit arch would take just 1 word (instead > of 2 it currently does). > > The diff to support packing of fields is in review [2], but to really > take advantage of it I think we need to introduce new primitive types: > - Int{8,16,32}# > - Word{8,16,32}# > along with some corresponding primops and with some other follow-up > changes like extending `PrimRep`. > > Then we could use them in definitions of `Int{8,16,32}` and > `Word{8,16,32}` (they're currently just wrapping `Int#` and `Word#`). > > Does that sound ok with everyone? (just making sure that this makes > sense before I invest more time into this :) > > Thanks, > Michal > > [1] https://ghc.haskell.org/trac/ghc/ticket/13825 > [2] https://phabricator.haskell.org/D3809 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at well-typed.com Wed Aug 2 02:03:51 2017 From: david at well-typed.com (David Feuer) Date: Tue, 01 Aug 2017 22:03:51 -0400 Subject: dataToTag# documentation Message-ID: <2217953.8DKWJPRY90@squirrel> dataToTag# is documented as getting the tag number of an enumeration, which is perfectly reasonable because it's designed to support deriving Enum. But it *appears* to work also for non-enumeration datatypes: dataToTag# Nothing = 0# dataToTag# (Just 3) = 1# Does this actually always work? If so, should that be documented, or is there a realistic possibility that its behavior will change in the future? Additionally: the documentation for dataToTag# urges readers to use GHC.Base.getTag instead. But dataToTag# is exported from the "public" GHC.Exts, whereas getTag is not. Should we add getTag to GHC.Exts, or change the documentation for dataToTag#? David From simonpj at microsoft.com Wed Aug 2 08:19:26 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 2 Aug 2017 08:19:26 +0000 Subject: dataToTag# documentation In-Reply-To: <2217953.8DKWJPRY90@squirrel> References: <2217953.8DKWJPRY90@squirrel> Message-ID: Based on memory rather that investigation: - yes it works on any data type - The reason that the primop dataToTag# is dangerous is that it does not evaluate its argument; it relies on the wrapper getTag to do so. Caveat emptor! It would be good to document this. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | David Feuer | Sent: 02 August 2017 03:04 | To: ghc-devs at haskell.org | Subject: dataToTag# documentation | | dataToTag# is documented as getting the tag number of an enumeration, | which is perfectly reasonable because it's designed to support | deriving Enum. | But it *appears* to work also for non-enumeration datatypes: | | dataToTag# Nothing = 0# | dataToTag# (Just 3) = 1# | | Does this actually always work? If so, should that be documented, or | is there a realistic possibility that its behavior will change in the | future? | | Additionally: the documentation for dataToTag# urges readers to use | GHC.Base.getTag instead. But dataToTag# is exported from the "public" | GHC.Exts, whereas getTag is not. Should we add getTag to GHC.Exts, or | change the documentation for dataToTag#? | | David | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=04%7C01%7Csimonpj%40microsoft.com%7C769c2a45735642edd36508d4 | d94a767e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363723612191322 | 18%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo | iT3RoZXIifQ%3D%3D%7C- | 1&sdata=585d0E3YyeKBk3DYqpvWR8ePnMR6bJ6%2Bu6dAGYk%2BNxo%3D&reserved=0 From simonpj at microsoft.com Wed Aug 2 08:21:10 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 2 Aug 2017 08:21:10 +0000 Subject: [commit: ghc] wip/T14068: Avoid name capture in setJoinResTy (6a50466) In-Reply-To: <20170802030713.6A4773A585@ghc.haskell.org> References: <20170802030713.6A4773A585@ghc.haskell.org> Message-ID: Joachim Aha! I think my comment on Phab is redundant. You are simply avoiding name capture, which is obviously right; you are not restricting the applicability of the transformation. Needless to say, a Note would help in due course. S | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf | Of git at git.haskell.org | Sent: 02 August 2017 04:07 | To: ghc-commits at haskell.org | Subject: [commit: ghc] wip/T14068: Avoid name capture in setJoinResTy | (6a50466) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : wip/T14068 | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha | skell.org%2Ftrac%2Fghc%2Fchangeset%2F6a5046684f93f1870663119b447fff6ba | eb7a7c4%2Fghc&data=04%7C01%7Csimonpj%40microsoft.com%7Cc45ce3f4deea476 | 9222b08d4d953af74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363724 | 00832017356%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi | IsIkFOIjoiT3RoZXIifQ%3D%3D%7C- | 1&sdata=29Iajm6oTE3Zm%2Bdl5ocMav7MPw%2FniO9%2BVeuQm38qWXQ%3D&reserved= | 0 | | >--------------------------------------------------------------- | | commit 6a5046684f93f1870663119b447fff6baeb7a7c4 | Author: Joachim Breitner | Date: Tue Aug 1 22:48:26 2017 -0400 | | Avoid name capture in setJoinResTy | | | >--------------------------------------------------------------- | | 6a5046684f93f1870663119b447fff6baeb7a7c4 | compiler/types/Type.hs | 22 ++++++++++++++++------ | 1 file changed, 16 insertions(+), 6 deletions(-) | | diff --git a/compiler/types/Type.hs b/compiler/types/Type.hs index | 50a35b0..c69d4ff 100644 | --- a/compiler/types/Type.hs | +++ b/compiler/types/Type.hs | @@ -2445,11 +2445,21 @@ setJoinResTy :: Int -- Number of binders to | skip | -> Type -- New type | -- INVARIANT: If any of the first n binders are foralls, those tyvars | cannot | -- appear in the original result type. See isValidJoinPointType. | +-- | +-- When we set the return type under a forall, avoid capture! | setJoinResTy orig_ar new_res_ty orig_ty | - = go orig_ar orig_ty | + = go init_subst orig_ar orig_ty | where | - go 0 _ = new_res_ty | - go n ty | Just (arg_bndr, res_ty) <- splitPiTy_maybe ty | - = mkPiTy arg_bndr (go (n-1) res_ty) | - | otherwise | - = pprPanic "setJoinResTy" (ppr orig_ar <+> ppr orig_ty) | + init_subst :: TCvSubst | + init_subst = mkEmptyTCvSubst (mkInScopeSet (tyCoVarsOfType | + new_res_ty)) | + | + go _ 0 _ = new_res_ty | + go subst n ty | + | Just (t, ty') <- splitForAllTy_maybe ty | + , let (subst', t') = substTyVarBndr subst t | + = mkForAllTy t' Inferred (go subst' (n-1) ty') | + | Just (arg_ty, ty') <- splitFunTy_maybe ty | + , let arg_ty' = substTy subst arg_ty | + = mkFunTy arg_ty' (go subst (n-1) ty') | + | otherwise | + = pprPanic "setJoinResTy" (ppr orig_ar <+> ppr orig_ty) | | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=04%7C01%7Csimonpj%40microsoft.com%7Cc45ce3f4deea4769222b0 | 8d4d953af74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363724008320 | 17356%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO | IjoiT3RoZXIifQ%3D%3D%7C- | 1&sdata=7%2FAY0EcihvMkjGOHdYdpOog2Roahk0XD%2BunNg54pKFc%3D&reserved=0 From sh.najd at gmail.com Wed Aug 2 10:50:02 2017 From: sh.najd at gmail.com (Shayan Najd) Date: Wed, 2 Aug 2017 11:50:02 +0100 Subject: Restructuring hsSyn Message-ID: Currently AST declarations, their relate utilities, and `Outputable` instances are defined in the same files. Does anyone object to moving `Outputable` instances to separate files? The purpose is to gradually identify reusable functionalities, group them together, polish them (e.g., remove some unnecessary dependencies), and expose them to the end-users. At this stage, I don't expect any changes outside hsSyn. /Shayan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Aug 2 11:06:47 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 2 Aug 2017 11:06:47 +0000 Subject: Restructuring hsSyn In-Reply-To: References: Message-ID: I don’t object. (They’d be orphan instances, so the interface file will always be loaded; but that’s probably ok. From: Shayan Najd [mailto:sh.najd at gmail.com] Sent: 02 August 2017 11:50 To: ghc-devs at haskell.org Cc: Simon Peyton Jones ; Alan & Kim Zimmerman Subject: Restructuring hsSyn Currently AST declarations, their relate utilities, and `Outputable` instances are defined in the same files. Does anyone object to moving `Outputable` instances to separate files? The purpose is to gradually identify reusable functionalities, group them together, polish them (e.g., remove some unnecessary dependencies), and expose them to the end-users. At this stage, I don't expect any changes outside hsSyn. /Shayan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Aug 2 11:07:38 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 2 Aug 2017 11:07:38 +0000 Subject: Occurrence info on binders and STG In-Reply-To: References: Message-ID: Can you be more specific? I don’t think occurrence info is used at all in STG. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gabor | Greif | Sent: 01 August 2017 16:02 | To: ghc-devs | Subject: Occurrence info on binders and STG | | Hi devs! | | I just had a short exchange with Joachim, he sent me to this place. | | Can anybody explain how occurrence info is used in STG? | | Cheers and thanks, | | Gabor | | ---------- Forwarded message ---------- | From: Joachim Breitner | Date: Tue, 01 Aug 2017 10:47:48 -0400 | Subject: Re: [commit: ghc] master: Simplify OccurAnal.tagRecBinders | (b311096) | To: Gabor Greif | | Hi, | | feel free to CC the mailing list on such questions. I often don’t know | things perfectly either. | | Am Dienstag, den 01.08.2017, 16:43 +0200 schrieb Gabor Greif: | | > | > Loosely related question: | | Very loosely :-) | | | > - when doing STG Cse, the occurrence info is not updated when a | > wild(card)-binder is used. Is there a recommended way to re-run | > occ-analysis on STG? (I fear there is not.) | | I fear that too. It the occ info used past that stage? | | > - I noticed that "wild"-binders sometimes do not appear at their | > binding site (after "of" and "{") in STG dumps. Dumping gets | > suppressed when they are deemed dead. Should STG consider occ-info at | > all? | | Good questions. I remember that Simon commented on that before, but I | don’t remember where… | | | > oachim | -- | Joachim “nomeata” Breitner | mail at joachim-breitner.de • | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joac | him- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cf811a87d003a4dd67 | ae908d4d8ee5b7a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636371965641 | 220522%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj | oiT3RoZXIifQ%3D%3D%7C- | 1&sdata=cKuY1cGPJnfqqaV1wwGU5qCORpiquDNbDeA0ppgKH%2Bc%3D&reserved=0 | XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F | Debian Developer: nomeata at debian.org | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=04%7C01%7Csimonpj%40microsoft.com%7Cf811a87d003a4dd67ae908d4d8e | e5b7a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636371965641220522%7CU | nknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT3RoZXIi | fQ%3D%3D%7C- | 1&sdata=IZBnhS28yxzjesQY%2B6j8%2B330rL1Vx2WO60r9nxPnOU0%3D&reserved=0 From ben at well-typed.com Wed Aug 2 15:47:09 2017 From: ben at well-typed.com (Ben Gamari) Date: Wed, 02 Aug 2017 11:47:09 -0400 Subject: GHC release timing and future build infrastructure In-Reply-To: References: Message-ID: <87a83ikm4i.fsf@ben-laptop.smart-cactus.org> Ara Adkins writes: > Heya, > > I very much agree with the thoughts on the variability of the release > cadence. The following is somewhat of a stream of consciousness as I > read, so please excuse any lack of coherence. > > When you talk about the bugs being significant blockers to the latest > release I feel like that kind of issue isn't necessarily touched by > moving to a shorter release cadence. In fact if we're unwilling to let > certain fixes wait a release then it exacerbates the risk of slowing > down a release. I'm not really sure what to do about this, other than > adopting the mentality that fixes might not make the major release and > will have to come in a point upgrade if they can't be merged to the > release branch in time. > You are to some extent correct; an unwillingness to release before major (for some definition of "major") bugs are fixed will inevitably lead to slips. However, I think a faster release cycle will make it easier to accept releases with such bugs (at least in the case of non-regressions). > Regarding the benefits of an abbreviated release cycle, we see it > quite a lot in the rust community. There's a good amount of community > involvement with the new releases, and new features are hotly > anticipated as they often occur on a timescale where the enthusiasm is > still there. I also feel, though this is purely anecdotal, that the > more agile release schedule encourages community contributions as the > tangible benefits of contributor work can be realised much more > quickly. The number of RFCs in discussion at the moment is evidence of > that, I feel. > > It's not all sunny, however, as having so many rapid releases means > that it's sometimes difficult to rally the community around certain > releases and feature sets. This is perhaps less of an issue due to the > maturity of GHC and its ecosystem, but, like you say, it's important > to find a good trade-off between release cadence and stability. > > Personally, I think Rust's cadence is a touch too short. On a related > note, there's a 'checkpoints' initiative to build rallying releases > that represent significant milestones in development [1]. This is, > however, also tied into Rust's stability story, so only parts of it > are relevant to GHC. > I agree that Rust is a bit extreme. Even with ideal tooling I don't think that GHC could manage the cadence maintained by Rust, nor do I think we should. The language is simply at a much different point in its evolution. Their strong adherence to stability certainly also helps. > In terms of automated tooling, I think there is significant benefit > from it. Again, using rust as an example, there is cargobomb [2], a > significant automated testing initiative that both combines packages > on Cargo, and runs their test suites. I feel that a combination of the > Stackage LTS and Nightly releases would provide a well-curated subset > of Hackage that could possibly be used in a similar fashion. This hits > on your item (b). > > Regarding your questions: > - In comparison to rust it can feel like there's significant delay in > being able to really use GHC's newest features. I feel like this delay > can hinder adoption of the features as much of the enthusiasm for them > has died down by the time they're properly available. > This seems to be a pretty widely held belief. It is very helpful to hear this clearly articulated. > - With the advent of tools such as `stack`, the compiler upgrade > process has almost become trivial. While not everyone uses it, it > requires no more work than upgrading to a new LTS release and running > `stack setup`. Nevertheless, I could imagine four upgrades a year > still being okay if it was manual. Indeed tools have improved remarkably in the Haskell community over the past few years. However, I feel like a word like "trivial" may be a bit strong here. Afterall, library authors still need to follow changes in core libraries (e.g. template-haskell, ghc-prim, and ghc itself). This does require effort, although perhaps on the part of a smaller number of people. > - The three release policy is an interesting case as the question of > changing it really comes down to how we view the GHC stability story. > Personally, I think we want to target a time-period of stability, > rather than a number of releases. Whether that time period is 1.5 > years (assuming a six-month release cadence), or 3 years (rounding the > current release cadence) seems like a totally independent discussion > to me. This makes sense. > - I think I've covered incentives to contribute in my discussion of > Rust above. > > I hope that's useful! Indeed it is. Thanks for taking the time to share! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From michal.terepeta at gmail.com Wed Aug 2 18:52:50 2017 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Wed, 02 Aug 2017 18:52:50 +0000 Subject: New primitive types? In-Reply-To: References: Message-ID: On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald wrote: > One issue with packed fields is that on many architectures you can't quite do subword reads or > writes. So it might not always be a win. Could you give any examples? Note that we're still going to do aligned read/writes, i.e., `Int32#` would still be 4 bytes aligned, `Int16#` 2 bytes, etc. So we might have "holes", e.g., `data Foo = Foo Int8# Int64#` would still waste 7 bytes (since `Int64#` should be 8 bytes aligned). In the future, I'd also like to do some field reordering to avoid some holes like that in cases like `Foo Int32# Int64# Int32#` (here it'd be better if the in-memory layout was `Int64#` first and then the two `Int32#`s) > There's also the issue that c-- as it exists in ghc doesn't have any notion of subword sized > types. > > That said, I do support making word/int64/32 # types more first class / built in. (I hit some > issues which tie into this topic in the process of working on my still in progress safeword > package. ) > > Point being: I support improving what we have, but it's got a bit of surface area. Please let me > know how I can help you dig into this though Have a look at https://ghc.haskell.org/trac/ghc/ticket/13825 which tracks the progress. The most recent diff is https://phabricator.haskell.org/D3809 So far, most of this work is based on some unfinished code by Simon Marlow to support storing constructor fields smaller than words. I'm currently mostly finishing/fixing it and splitting to smaller pieces. Introducing more primitive stuff is the next step. (assuming everyone is ok with this :) Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Wed Aug 2 19:26:49 2017 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 2 Aug 2017 21:26:49 +0200 Subject: GHC release timing and future build infrastructure In-Reply-To: References: Message-ID: On 2017-08-01 15:05, Ara Adkins wrote: > Heya, > > I very much agree with the thoughts on the variability of the release > cadence. The following is somewhat of a stream of consciousness as I > read, so please excuse any lack of coherence. > > When you talk about the bugs being significant blockers to the latest > release I feel like that kind of issue isn't necessarily touched by > moving to a shorter release cadence. In fact if we're unwilling to let > certain fixes wait a release then it exacerbates the risk of slowing > down a release. I'm not really sure what to do about this, other than > adopting the mentality that fixes might not make the major release and > will have to come in a point upgrade if they can't be merged to the > release branch in time. > > Regarding the benefits of an abbreviated release cycle, we see it quite > a lot in the rust community. There's a good amount of community > involvement with the new releases, and new features are hotly > anticipated as they often occur on a timescale where the enthusiasm is > still there. I also feel, though this is purely anecdotal, that the more > agile release schedule encourages community contributions as the > tangible benefits of contributor work can be realised much more quickly. > The number of RFCs in discussion at the moment is evidence of that, I feel. (Sorry, this is also kind of a braindump.) I'd like to add a few thoughs (or just to underscore the ones you've already brought forth, as the case may be): - In the case of e.g. the Linux kernel, there's a pretty good assurance that *someone* will maintain a "stable" release of a reasonably-recent version of the kernel and backport(!) patches for, say, up to a year (either distros or the 'stable' kernel maintainer & co). In the case of the Linux kernel backporting will *usually* not be that much work, but in the case of GHC it *might* be a lot more work for any number of reasons -- I wouldn't presume to know. Also note that this is *basically* how Rust also works, it's just that they keep the "unstable" bits behind a feature flag (until they're deemed 'stable') instead of actually having different code bases. - Releasing often means that *all* the upstreams who care(!) get to "start" early as well. (RCs notwithstanding) See e.g. Stackage. - Releasing often means that any serious bugs that get into a release can also get a *release* that fixes them ASAP (and this is important:) *independent* of any other release-blocking bugs in *upcoming* features. This is a Big Deal(TM) and I think it's why the Linux kernel model works at all. - Releasing often means that there isn't this absolutely mad rush to get $YOUR_FEATURE in before the deadline, because what's another 3/6 months in the grand scheme of things? When you don't know if $FEATURE will make it in in ½ year or 2 years, then it's a problem -- and you rush like mad (likely making miskakes in the process). - As a corollary to that: It is *paramount* that the release schedule is adhered to *quite* strictly. This is also, I believe, key to its success in the Linux kernel and Rust community. It doesn't matter much if feature "X" makes it in -- it'll be in the next soon-to-come release. - And, yes, this means a serious committment to improving the tooling/automation around GHC releases. Regards, From michal.terepeta at gmail.com Wed Aug 2 19:30:01 2017 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Wed, 02 Aug 2017 19:30:01 +0000 Subject: GHC release timing and future build infrastructure In-Reply-To: <8760e8m3mt.fsf@ben-laptop.smart-cactus.org> References: <8760e8m3mt.fsf@ben-laptop.smart-cactus.org> Message-ID: On Tue, Aug 1, 2017 at 4:19 AM Ben Gamari wrote: > > Hello everyone, > > I just posted a pair of posts on the GHC blog [1,2] laying out some > thoughts on the GHC release cycle timing [1] and how this relates to the > in-progress Jenkins build infrastructure [2]. When you have a some time > feel free to give them a read and comment (either here or on the Reddit > thread [3]). > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule > [2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci > [3] > https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_ghcs_release_schedule/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs Hi Ben, This sounds really cool! I'm pretty excited about more automation and GHC releases more than once a year (maybe every 6 months?). In my experience both automation and regular releases are a significant win. They often result in more and quicker feedback, are more motivating and make it easier to iterate/improve the project and keep it in "releasable" state. So thanks a lot for working on this! :) Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Wed Aug 2 20:54:59 2017 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 2 Aug 2017 22:54:59 +0200 Subject: GHC release timing and future build infrastructure In-Reply-To: References: Message-ID: On 2017-08-02 21:26, Bardur Arantsson wrote: > I'd like to add a few thoughs (or just to underscore the ones you've > already brought forth, as the case may be): > [--snip--] > reasons -- I wouldn't presume to know. Also note that this is > *basically* how Rust also works, it's just that they keep the "unstable" > bits behind a feature flag (until they're deemed 'stable') instead of > actually having different code bases. > Sorry about the self-reply and excesive bolding-for-emphasis. The point of this past paragraph was that *perhaps* GHC could move towards (short-lived!) "feature flags" for the compiler[1]. Again, I have no experience with the GHC development process so maybe it's completely absurd to even contemplate such a thing (in terms of effort). Continuing with the thought from [1]: What if there were "stability tiers" of LANGUAGE PRAGMA? Obviously, it doesn't *literally* have to be like that, but maybe the concept works? [1] I suppose LANGUAGE Pragmas are *kind* of like feature flags, but IME LANGUAGE Pragmas tend to be actually be quite long-lived. Regards, From ben at smart-cactus.org Wed Aug 2 21:57:55 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 02 Aug 2017 17:57:55 -0400 Subject: Limited availability next week Message-ID: <87a83hk4yk.fsf@ben-laptop.smart-cactus.org> Hello everyone, I will be travelling starting tomorrow through next week. During this time I'll still try to check in on things once a day to make sure nothing is burning down. However, I will be a bit less available. Still feel free to ping me via email or IRC, however. I'll try to get back to you. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From sylvain at haskus.fr Thu Aug 3 00:27:41 2017 From: sylvain at haskus.fr (Sylvain Henry) Date: Thu, 3 Aug 2017 02:27:41 +0200 Subject: New primitive types? In-Reply-To: References: Message-ID: Hi, I also think we should do this but it has a lot of ramifications: contant folding in Core, codegen, TH, etc. Also it will break codes that use primitive types directly, so maybe it's worth a ghc proposal. Sylvain On 01/08/2017 15:37, Michal Terepeta wrote: > Hi all, > > I'm working on making it possible to pack constructor fields [1], > example: > > ``` > data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Int32 > ``` > > should only require 4 bytes for unpacked `Float` and 4 bytes for > unpacked `Int32`, which on 64-bit arch would take just 1 word (instead > of 2 it currently does). > > The diff to support packing of fields is in review [2], but to really > take advantage of it I think we need to introduce new primitive types: > - Int{8,16,32}# > - Word{8,16,32}# > along with some corresponding primops and with some other follow-up > changes like extending `PrimRep`. > > Then we could use them in definitions of `Int{8,16,32}` and > `Word{8,16,32}` (they're currently just wrapping `Int#` and `Word#`). > > Does that sound ok with everyone? (just making sure that this makes > sense before I invest more time into this :) > > Thanks, > Michal > > [1] https://ghc.haskell.org/trac/ghc/ticket/13825 > [2] https://phabricator.haskell.org/D3809 > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Thu Aug 3 01:10:30 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 02 Aug 2017 21:10:30 -0400 Subject: GHC release timing and future build infrastructure In-Reply-To: References: Message-ID: <87k22lihh5.fsf@ben-laptop.smart-cactus.org> Bardur Arantsson writes: > On 2017-08-02 21:26, Bardur Arantsson wrote: > >> I'd like to add a few thoughs (or just to underscore the ones you've >> already brought forth, as the case may be): >> > [--snip--] >> reasons -- I wouldn't presume to know. Also note that this is >> *basically* how Rust also works, it's just that they keep the "unstable" >> bits behind a feature flag (until they're deemed 'stable') instead of >> actually having different code bases. >> > > Sorry about the self-reply and excesive bolding-for-emphasis. The point > of this past paragraph was that *perhaps* GHC could move towards > (short-lived!) "feature flags" for the compiler[1]. Again, I have no > experience with the GHC development process so maybe it's completely > absurd to even contemplate such a thing (in terms of effort). > It's not clear to me that this would work. Afterall, not all commits are new features and, perhaps more importantly, not all bugs stem from new features. Rather, many of GHCs commits are in fact refactorings. This is one of the major reasons why the codebase hasn't collapsed under its own weight despite the last two decades of development. Sometimes these refactorings are merely cleanups, sometimes they fix bugs, but sometimes they also introduce bugs. In principle, the role of a stable branch is to serve as a "known good" state which we can place fixes that we are quite certain fix a bug without knowingly introducing others. Of course, in part due to our long release schedule, we have in practice been a bit more liberal in backporting. That being said, I do fear that including all new commits, even those that don't fix bugs, in all new releases may have the effect of destabilizing those releases. Of course, feel free to clarify if I've misunderstood the proposal (which I fear I may have). Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Thu Aug 3 01:48:41 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 02 Aug 2017 21:48:41 -0400 Subject: Restructuring hsSyn In-Reply-To: References: Message-ID: <87bmnxifpi.fsf@ben-laptop.smart-cactus.org> Shayan Najd writes: > Currently AST declarations, their relate utilities, and `Outputable` > instances are defined in the same files. > Does anyone object to moving `Outputable` instances to separate files? > The purpose is to gradually identify reusable functionalities, group them > together, polish them (e.g., remove some unnecessary dependencies), and > expose them to the end-users. > At this stage, I don't expect any changes outside hsSyn. > Sounds reasonable to me. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From me at ara.io Thu Aug 3 06:41:59 2017 From: me at ara.io (Ara Adkins) Date: Thu, 3 Aug 2017 07:41:59 +0100 Subject: GHC release timing and future build infrastructure In-Reply-To: <87a83ikm4i.fsf@ben-laptop.smart-cactus.org> References: <87a83ikm4i.fsf@ben-laptop.smart-cactus.org> Message-ID: <0B19311D-F95B-4B5E-B4A6-EB00D1DAF927@ara.io> Glad I could provide some useful thoughts! > You are to some extent correct; an unwillingness to release before major > (for some definition of "major") bugs are fixed will inevitably lead to > slips. However, I think a faster release cycle will make it easier to > accept releases with such bugs (at least in the case of non-regressions). I definitely agree that a shortened release cadence would help with the reduction of release blockers by making som things more acceptable. I think this would be one of the major benefits of shortening the release cycle. > I agree that Rust is a bit extreme. Even with ideal tooling I don't > think that GHC could manage the cadence maintained by Rust, nor do I > think we should. The language is simply at a much different point in its > evolution. Their strong adherence to stability certainly also helps. I'm definitely with you here. I think that a 3-month release cycle is the shortest that would work for GHC, but that would require a perfect set of tooling which we don't quite have yet. Your originally proposed six months sounds great to me, and I don't see an reason why it couldn't be altered further down the line if it wasn't quite working. > Indeed tools have improved remarkably in the Haskell community over the > past few years. However, I feel like a word like "trivial" may be a bit > strong here. Afterall, library authors still need to follow changes in > core libraries (e.g. template-haskell, ghc-prim, and ghc itself). This > does require effort, although perhaps on the part of a smaller number of > people. Trivial was perhaps somewhat overstating the current state of the ecosystem, yes. I nevertheless see `stack` as a huge boon for easing adoption of new compiler versions (and hence new language features/extensions). _ara > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Thu Aug 3 08:38:38 2017 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 03 Aug 2017 10:38:38 +0200 Subject: GHC release timing and future build infrastructure In-Reply-To: <0B19311D-F95B-4B5E-B4A6-EB00D1DAF927@ara.io> (Ara Adkins's message of "Thu, 3 Aug 2017 07:41:59 +0100") References: <87a83ikm4i.fsf@ben-laptop.smart-cactus.org> <0B19311D-F95B-4B5E-B4A6-EB00D1DAF927@ara.io> Message-ID: <8737996o6p.fsf@gmail.com> Hi! On 2017-08-03 at 08:41:59 +0200, Ara Adkins wrote: [...] > I nevertheless see `stack` as a huge boon for easing adoption of new > compiler versions (and hence new language features/extensions). Since I totally disagree about Stack being beneficial to the quick adoption of new features, would you care to elaborate what makes you think that Stack was a "huge boon" in this particular context? Just to name one example where Stack has been lagging behind Cabal for several months already: Support for Backpack or convenience libraries -- there's already a handful of packages on Hackage which Stack (and consequently Stackage) cannot install due to this. Being slow to adopt new features IMO makes totally sense for Stack, as it's target audience is practicioners who value stability, "reproducibility" and "long term support", so it's actually a good thing that Stack stays behind until we iron out issues with new bleeding edge features and Stack(age) adopts them only when they're officially released and deemed ready for Stack's target audience. -- hvr From me at ara.io Thu Aug 3 13:04:54 2017 From: me at ara.io (Ara Adkins) Date: Thu, 3 Aug 2017 14:04:54 +0100 Subject: GHC release timing and future build infrastructure In-Reply-To: <8737996o6p.fsf@gmail.com> References: <87a83ikm4i.fsf@ben-laptop.smart-cactus.org> <0B19311D-F95B-4B5E-B4A6-EB00D1DAF927@ara.io> <8737996o6p.fsf@gmail.com> Message-ID: I definitely agree with what you're saying around some of the features that require external support such as backpack. I think my statement was focused more on new language features that don't require additional support, as with stack getting access to those is as simple as hopping on the latest nightly release. On Thu, Aug 3, 2017 at 9:38 AM, Herbert Valerio Riedel wrote: > Hi! > > On 2017-08-03 at 08:41:59 +0200, Ara Adkins wrote: > > [...] > > > I nevertheless see `stack` as a huge boon for easing adoption of new > > compiler versions (and hence new language features/extensions). > > Since I totally disagree about Stack being beneficial to the quick > adoption of new features, would you care to elaborate what makes you > think that Stack was a "huge boon" in this particular context? > > Just to name one example where Stack has been lagging behind Cabal for > several months already: Support for Backpack or convenience libraries -- > there's already a handful of packages on Hackage which Stack (and > consequently Stackage) cannot install due to this. Being slow to adopt > new features IMO makes totally sense for Stack, as it's target audience > is practicioners who value stability, "reproducibility" and "long term > support", so it's actually a good thing that Stack stays behind until we > iron out issues with new bleeding edge features and Stack(age) adopts > them only when they're officially released and deemed ready for Stack's > target audience. > > -- hvr > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Thu Aug 3 22:21:36 2017 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 3 Aug 2017 15:21:36 -0700 Subject: Debugging inside the typechecker knot Message-ID: Recently, I've found myself wanting to make changes to code that works inside code where TyCons are knot-tied [1]. But I've found myself unable to make much progress, since my ability to debug this code is severely limited by the fact that I can't seem to trace anything. That is, if I try tracing anything that comes from a knot-tied TyCon, GHC will go into an infinite loop! This prevents me from learning *anything* about the types floating around in the code I want to fix, which is hugely annoying. How do others work around this problem? There must be *some* way to glean information about the types inside a typechecker knot, since others seem to be able to work within this space. How do you do it? And will you consider sharing your secrets? Ryan S. ----- [1] See Note [Type-checking inside the knot] at http://git.haskell.org/ghc.git/blob/884bd21a917f607b5a44e038e06f78d0b765ea63:/compiler/typecheck/TcHsType.hs#l1087 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Fri Aug 4 14:33:53 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 4 Aug 2017 10:33:53 -0400 Subject: Debugging inside the typechecker knot In-Reply-To: References: Message-ID: <1AD042D4-3FA0-4CDF-B920-CC757C09F911@cs.brynmawr.edu> My secret is that I've been annoyed by this problem, too! Perhaps a better answer is that you probably don't need the information you don't have. All the type-checking decisions are around the kinds of the types floating through the system, so look there. You might want to know what type that kind is classifying... perhaps print out the HsType before it's lost. Or, you could tackle #13737 and get rid of the knot altogether! :) Richard > On Aug 3, 2017, at 6:21 PM, Ryan Scott wrote: > > Recently, I've found myself wanting to make changes to code that works inside code where TyCons are knot-tied [1]. But I've found myself unable to make much progress, since my ability to debug this code is severely limited by the fact that I can't seem to trace anything. That is, if I try tracing anything that comes from a knot-tied TyCon, GHC will go into an infinite loop! This prevents me from learning *anything* about the types floating around in the code I want to fix, which is hugely annoying. > > How do others work around this problem? There must be *some* way to glean information about the types inside a typechecker knot, since others seem to be able to work within this space. How do you do it? And will you consider sharing your secrets? > > Ryan S. > ----- > [1] See Note [Type-checking inside the knot] at http://git.haskell.org/ghc.git/blob/884bd21a917f607b5a44e038e06f78d0b765ea63:/compiler/typecheck/TcHsType.hs#l1087 _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Fri Aug 4 16:43:53 2017 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 4 Aug 2017 09:43:53 -0700 Subject: Debugging inside the typechecker knot In-Reply-To: <1AD042D4-3FA0-4CDF-B920-CC757C09F911@cs.brynmawr.edu> References: <1AD042D4-3FA0-4CDF-B920-CC757C09F911@cs.brynmawr.edu> Message-ID: > All the type-checking decisions are around the kinds of the types floating through the system, so look there. You might want to know what type that kind is classifying... perhaps print out the HsType before it's lost. In the problems I'm tackling, I don't care so much about the kind of the TyCon I'm dealing with, but rather its type variables. Alas, I don't know of a good way to inspect the changes that happen to these type variables inside the knot--even printing out the *length* of tyConTyVars would result in an infinite loop! > Or, you could tackle #13737 and get rid of the knot altogether! :) I didn't know about that ticket, thanks. I had noticed in some of the code I frequently look at (TcGenGenerics, which generates Generic(1) instances) that the generated code uses HsExpr for the generated instance methods, but Type for the generated associated type family instances, which always felt icky to me. Maybe I could start by trying to produce HsType in that particular spot in the code (or does this need to be done all at once?). Ryan S. On Fri, Aug 4, 2017 at 7:33 AM, Richard Eisenberg wrote: > My secret is that I've been annoyed by this problem, too! > > Perhaps a better answer is that you probably don't need the information > you don't have. All the type-checking decisions are around the kinds of the > types floating through the system, so look there. You might want to know > what type that kind is classifying... perhaps print out the HsType before > it's lost. > > Or, you could tackle #13737 and get rid of the knot altogether! :) > > Richard > > On Aug 3, 2017, at 6:21 PM, Ryan Scott wrote: > > Recently, I've found myself wanting to make changes to code that works > inside code where TyCons are knot-tied [1]. But I've found myself unable to > make much progress, since my ability to debug this code is severely limited > by the fact that I can't seem to trace anything. That is, if I try tracing > anything that comes from a knot-tied TyCon, GHC will go into an infinite > loop! This prevents me from learning *anything* about the types floating > around in the code I want to fix, which is hugely annoying. > > How do others work around this problem? There must be *some* way to glean > information about the types inside a typechecker knot, since others seem to > be able to work within this space. How do you do it? And will you consider > sharing your secrets? > > Ryan S. > ----- > [1] See Note [Type-checking inside the knot] at > http://git.haskell.org/ghc.git/blob/884bd21a917f607b5a44e038e06f78 > d0b765ea63:/compiler/typecheck/TcHsType.hs#l1087 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Fri Aug 4 16:45:15 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 4 Aug 2017 12:45:15 -0400 Subject: Debugging inside the typechecker knot In-Reply-To: References: <1AD042D4-3FA0-4CDF-B920-CC757C09F911@cs.brynmawr.edu> Message-ID: <1F0D052B-4225-4E0C-9805-D0C85E9980BF@cs.brynmawr.edu> > On Aug 4, 2017, at 12:43 PM, Ryan Scott wrote: > > Maybe I could start by trying to produce HsType in that particular spot in the code (or does this need to be done all at once?). I don't know. I haven't looked into this at all, really. Any light you can shed will be helpful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnw at newartisans.com Fri Aug 4 17:03:12 2017 From: johnw at newartisans.com (John Wiegley) Date: Fri, 04 Aug 2017 10:03:12 -0700 Subject: Debugging inside the typechecker knot In-Reply-To: <1AD042D4-3FA0-4CDF-B920-CC757C09F911@cs.brynmawr.edu> (Richard Eisenberg's message of "Fri, 4 Aug 2017 10:33:53 -0400") References: <1AD042D4-3FA0-4CDF-B920-CC757C09F911@cs.brynmawr.edu> Message-ID: >>>>> "RE" == Richard Eisenberg writes: RE> Or, you could tackle #13737 and get rid of the knot altogether! :) That would be helpful. :) -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From conal at conal.net Sat Aug 5 21:22:20 2017 From: conal at conal.net (Conal Elliott) Date: Sat, 5 Aug 2017 14:22:20 -0700 Subject: Job opening: compiling to categories Message-ID: I have a job opening to work closely with me (at Target Digital) on the GHC plugin described in the paper *Compiling to Categories* as well as on applications, including machine learning. I’m especially looking for someone used to working inside of GHC and/or on GHC plugins. Mathematically oriented, solid background in programming language theory, denotationally inclined. Remote work is perfectly fine (and is what I do). – Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.frisby at gmail.com Sun Aug 6 01:27:53 2017 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Sun, 06 Aug 2017 01:27:53 +0000 Subject: How does GHC handle TcPluginContradiction? Message-ID: My TC plugin is identifying a contradiction, but that is not preventing the module from type checking, nor does GHC even raising a warning (with -Wall). This is not the behavior I was expecting. How confused am I? I've distilled the behavior that's confusing me down to the following example > module Test where > > class C a where f :: a -> () paired with a very silly plugin that always claims every constraint it sees is a contradiction. > module Contrarian (plugin) where > > import Plugins (Plugin(..),defaultPlugin) > import TcPluginM (tcPluginIO) > import TcRnTypes (TcPlugin(..),TcPluginResult(TcPluginContradiction)) > > plugin :: Plugin > plugin = defaultPlugin { tcPlugin = const (Just contrarianPlugin) } > > contrarianPlugin :: TcPlugin > contrarianPlugin = TcPlugin { > tcPluginInit = return () > , > tcPluginSolve = \() given derived wanted -> do > tcPluginIO $ putStrLn "Alternative facts!" > return $ TcPluginContradiction $ given ++ derived ++ wanted > , > tcPluginStop = \() -> return () > } Please review the following GHCi session. We start *without* the plugin. $ ghc --interactive Test.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Test ( Test.hs, interpreted ) Ok, 1 module loaded. *Test> f () :1:1: error: * No instance for (C ()) arising from a use of `f' * In the expression: f () In an equation for `it': it = f () That behavior meets my expectations. Now let's add the plugin to see what contradictions cause to happen --- my naive guess is that we should see the same thing. (I don't really know what contradictions *should* cause GHC to do *differently* than the above.) The following is a continuation of the same session. *Test> :set -fplugin=Contrarian *Test> f () Alternative facts! Alternative facts! Alternative facts! Alternative facts! *** Exception: :3:1: error: * No instance for (C ()) arising from a use of `f' * In the expression: f () In an equation for `it': it = f () (deferred type error) *Test> :t f Alternative facts! f :: a -> () Interesting: claiming the constraint is a contradiction seems to convert the type error to a deferred type error. Let's see if we can disable that (since it's not the behavior I want). *Test> :set -fno-defer-type-errors *Test> :t f Alternative facts! f :: a -> () *Test> f () Alternative facts! Alternative facts! Alternative facts! Alternative facts! *** Exception: :3:1: error: * No instance for (C ()) arising from a use of `f' * In the expression: f () In an equation for `it': it = f () (deferred type error) :7:1: error: * No instance for (Show (a0 -> ())) arising from a use of `print' (maybe you haven't applied a function to enough arguments?) * In a stmt of an interactive GHCi command: print it *Test> I seems we can't disable this behavior. That makes it seem pretty fundamental. So I'm guessing I'm confused about something, probably what TcContradiction achieves in terms of the user experience. The behavior I want is for my plugin to identify (relevant) contradictions and incur a static type error as soon as possible. I thought contradictions would achieve that, but I seem to be wrong. What I should be expecting regarding contradictions? How should I achieve my desired behavior? Perhaps I should try "solving" the contradiction constraints via an appeal to a TypeError constraint instead. Or maybe I should just leave the identified contradictions unsolved? Thanks. -Nick PS - A big thank you to Adam Gundry and Christiaan Baaij (and probably others) for the useful wiki pages, blog posts, and publications -- they've been a huge help for my learning about the typechecker via plugins! I'm very excited about this plugin, and I hope to share it soon, but I'd like to understand it better before I do. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Sun Aug 6 02:27:16 2017 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 05 Aug 2017 22:27:16 -0400 Subject: How does GHC handle TcPluginContradiction? In-Reply-To: References: Message-ID: <1501985146-sup-5003@sabre> Hi Nicolas, While I am not 100% sure, I belive this is related to the fact that currently inaccessible branches (a local contradiction indicates inaccessibility) are not being reported in GHC. I reported this in https://ghc.haskell.org/trac/ghc/ticket/12694 whose root cause was suggested might be https://ghc.haskell.org/trac/ghc/ticket/12466 Edward Excerpts from Nicolas Frisby's message of 2017-08-06 01:27:53 +0000: > My TC plugin is identifying a contradiction, but that is not preventing the > module from type checking, nor does GHC even raising a warning (with > -Wall). This is not the behavior I was expecting. How confused am I? > > I've distilled the behavior that's confusing me down to the following > example > > > module Test where > > > > class C a where f :: a -> () > > paired with a very silly plugin that always claims every constraint it sees > is a contradiction. > > > module Contrarian (plugin) where > > > > import Plugins (Plugin(..),defaultPlugin) > > import TcPluginM (tcPluginIO) > > import TcRnTypes (TcPlugin(..),TcPluginResult(TcPluginContradiction)) > > > > plugin :: Plugin > > plugin = defaultPlugin { tcPlugin = const (Just contrarianPlugin) } > > > > contrarianPlugin :: TcPlugin > > contrarianPlugin = TcPlugin { > > tcPluginInit = return () > > , > > tcPluginSolve = \() given derived wanted -> do > > tcPluginIO $ putStrLn "Alternative facts!" > > return $ TcPluginContradiction $ given ++ derived ++ wanted > > , > > tcPluginStop = \() -> return () > > } > > Please review the following GHCi session. We start *without* the plugin. > > $ ghc --interactive Test.hs > GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Test ( Test.hs, interpreted ) > Ok, 1 module loaded. > *Test> f () > > :1:1: error: > * No instance for (C ()) arising from a use of `f' > * In the expression: f () > In an equation for `it': it = f () > > That behavior meets my expectations. Now let's add the plugin to see what > contradictions cause to happen --- my naive guess is that we should see the > same thing. (I don't really know what contradictions *should* cause GHC to > do *differently* than the above.) The following is a continuation of the > same session. > > *Test> :set -fplugin=Contrarian > *Test> f () > Alternative facts! > Alternative facts! > Alternative facts! > Alternative facts! > *** Exception: :3:1: error: > * No instance for (C ()) arising from a use of `f' > * In the expression: f () > In an equation for `it': it = f () > (deferred type error) > *Test> :t f > Alternative facts! > f :: a -> () > > Interesting: claiming the constraint is a contradiction seems to convert > the type error to a deferred type error. Let's see if we can disable that > (since it's not the behavior I want). > > *Test> :set -fno-defer-type-errors > *Test> :t f > Alternative facts! > f :: a -> () > *Test> f () > Alternative facts! > Alternative facts! > Alternative facts! > Alternative facts! > *** Exception: :3:1: error: > * No instance for (C ()) arising from a use of `f' > * In the expression: f () > In an equation for `it': it = f () > (deferred type error) > > :7:1: error: > * No instance for (Show (a0 -> ())) arising from a use of `print' > (maybe you haven't applied a function to enough arguments?) > * In a stmt of an interactive GHCi command: print it > *Test> > > I seems we can't disable this behavior. That makes it seem pretty > fundamental. So I'm guessing I'm confused about something, probably what > TcContradiction achieves in terms of the user experience. > > The behavior I want is for my plugin to identify (relevant) contradictions > and incur a static type error as soon as possible. I thought contradictions > would achieve that, but I seem to be wrong. > > What I should be expecting regarding contradictions? > > How should I achieve my desired behavior? Perhaps I should try "solving" > the contradiction constraints via an appeal to a TypeError constraint > instead. Or maybe I should just leave the identified contradictions > unsolved? > > Thanks. -Nick > > PS - A big thank you to Adam Gundry and Christiaan Baaij (and probably > others) for the useful wiki pages, blog posts, and publications -- they've > been a huge help for my learning about the typechecker via plugins! I'm > very excited about this plugin, and I hope to share it soon, but I'd like > to understand it better before I do. From nicolas.frisby at gmail.com Sun Aug 6 02:46:08 2017 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Sun, 06 Aug 2017 02:46:08 +0000 Subject: How does GHC handle TcPluginContradiction? In-Reply-To: <1501985146-sup-5003@sabre> References: <1501985146-sup-5003@sabre> Message-ID: Yes, thanks! I agree with you. I just realized on my dog walk that, according to https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker, "If the plugin finds a contradiction amongst the givens, it should return TcPluginContradiction containing the contradictory constraints. These will turn into inaccessible code errors." And the brief demo in my previous email seems to indicate that "inaccessible code errors" are only realized as deferred type errors, with no static manifestation. Thanks. -Nick On Sat, Aug 5, 2017 at 7:27 PM Edward Z. Yang wrote: > Hi Nicolas, > > While I am not 100% sure, I belive this is related to > the fact that currently inaccessible branches (a local > contradiction indicates inaccessibility) are not > being reported in GHC. I reported this in > https://ghc.haskell.org/trac/ghc/ticket/12694 > whose root cause was suggested might be > https://ghc.haskell.org/trac/ghc/ticket/12466 > > Edward > > Excerpts from Nicolas Frisby's message of 2017-08-06 01:27:53 +0000: > > My TC plugin is identifying a contradiction, but that is not preventing > the > > module from type checking, nor does GHC even raising a warning (with > > -Wall). This is not the behavior I was expecting. How confused am I? > > > > I've distilled the behavior that's confusing me down to the following > > example > > > > > module Test where > > > > > > class C a where f :: a -> () > > > > paired with a very silly plugin that always claims every constraint it > sees > > is a contradiction. > > > > > module Contrarian (plugin) where > > > > > > import Plugins (Plugin(..),defaultPlugin) > > > import TcPluginM (tcPluginIO) > > > import TcRnTypes (TcPlugin(..),TcPluginResult(TcPluginContradiction)) > > > > > > plugin :: Plugin > > > plugin = defaultPlugin { tcPlugin = const (Just contrarianPlugin) } > > > > > > contrarianPlugin :: TcPlugin > > > contrarianPlugin = TcPlugin { > > > tcPluginInit = return () > > > , > > > tcPluginSolve = \() given derived wanted -> do > > > tcPluginIO $ putStrLn "Alternative facts!" > > > return $ TcPluginContradiction $ given ++ derived ++ wanted > > > , > > > tcPluginStop = \() -> return () > > > } > > > > Please review the following GHCi session. We start *without* the plugin. > > > > $ ghc --interactive Test.hs > > GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help > > [1 of 1] Compiling Test ( Test.hs, interpreted ) > > Ok, 1 module loaded. > > *Test> f () > > > > :1:1: error: > > * No instance for (C ()) arising from a use of `f' > > * In the expression: f () > > In an equation for `it': it = f () > > > > That behavior meets my expectations. Now let's add the plugin to see what > > contradictions cause to happen --- my naive guess is that we should see > the > > same thing. (I don't really know what contradictions *should* cause GHC > to > > do *differently* than the above.) The following is a continuation of the > > same session. > > > > *Test> :set -fplugin=Contrarian > > *Test> f () > > Alternative facts! > > Alternative facts! > > Alternative facts! > > Alternative facts! > > *** Exception: :3:1: error: > > * No instance for (C ()) arising from a use of `f' > > * In the expression: f () > > In an equation for `it': it = f () > > (deferred type error) > > *Test> :t f > > Alternative facts! > > f :: a -> () > > > > Interesting: claiming the constraint is a contradiction seems to convert > > the type error to a deferred type error. Let's see if we can disable that > > (since it's not the behavior I want). > > > > *Test> :set -fno-defer-type-errors > > *Test> :t f > > Alternative facts! > > f :: a -> () > > *Test> f () > > Alternative facts! > > Alternative facts! > > Alternative facts! > > Alternative facts! > > *** Exception: :3:1: error: > > * No instance for (C ()) arising from a use of `f' > > * In the expression: f () > > In an equation for `it': it = f () > > (deferred type error) > > > > :7:1: error: > > * No instance for (Show (a0 -> ())) arising from a use of `print' > > (maybe you haven't applied a function to enough arguments?) > > * In a stmt of an interactive GHCi command: print it > > *Test> > > > > I seems we can't disable this behavior. That makes it seem pretty > > fundamental. So I'm guessing I'm confused about something, probably what > > TcContradiction achieves in terms of the user experience. > > > > The behavior I want is for my plugin to identify (relevant) > contradictions > > and incur a static type error as soon as possible. I thought > contradictions > > would achieve that, but I seem to be wrong. > > > > What I should be expecting regarding contradictions? > > > > How should I achieve my desired behavior? Perhaps I should try "solving" > > the contradiction constraints via an appeal to a TypeError constraint > > instead. Or maybe I should just leave the identified contradictions > > unsolved? > > > > Thanks. -Nick > > > > PS - A big thank you to Adam Gundry and Christiaan Baaij (and probably > > others) for the useful wiki pages, blog posts, and publications -- > they've > > been a huge help for my learning about the typechecker via plugins! I'm > > very excited about this plugin, and I hope to share it soon, but I'd like > > to understand it better before I do. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.frisby at gmail.com Sun Aug 6 04:58:10 2017 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Sun, 06 Aug 2017 04:58:10 +0000 Subject: How does GHC handle TcPluginContradiction? In-Reply-To: References: <1501985146-sup-5003@sabre> Message-ID: I also just found issue #22 in Adam's uom github repository; it seems related. """ The plugin is correctly reporting the constraint Base "s" ~~ Base "m" ^: 2 as insoluble (note the use of ~~, which is a type family provided by uom-plugin that is a pseudo-synonym of ~). However, it turns out that the GHC error-reporting machinery requires a subtle invariant, namely that only certain kinds of constraint can be regarded as insoluble. Equalities are included, but not irreducible predicates such as ~~. Failure to respect this invariant means that errors are silently ignored. """ The insoluble constraints in my actual plugin is a genuine class, so this isn't an obvious perfect fit for my case. On Sat, Aug 5, 2017 at 7:46 PM Nicolas Frisby wrote: > Yes, thanks! I agree with you. > > I just realized on my dog walk that, according to > https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker, "If the plugin > finds a contradiction amongst the givens, it should return > TcPluginContradiction containing the contradictory constraints. These will > turn into inaccessible code errors." > > And the brief demo in my previous email seems to indicate that > "inaccessible code errors" are only realized as deferred type errors, with > no static manifestation. > > Thanks. -Nick > > > On Sat, Aug 5, 2017 at 7:27 PM Edward Z. Yang wrote: > >> Hi Nicolas, >> >> While I am not 100% sure, I belive this is related to >> the fact that currently inaccessible branches (a local >> contradiction indicates inaccessibility) are not >> being reported in GHC. I reported this in >> https://ghc.haskell.org/trac/ghc/ticket/12694 >> whose root cause was suggested might be >> https://ghc.haskell.org/trac/ghc/ticket/12466 >> >> Edward >> >> Excerpts from Nicolas Frisby's message of 2017-08-06 01:27:53 +0000: >> > My TC plugin is identifying a contradiction, but that is not preventing >> the >> > module from type checking, nor does GHC even raising a warning (with >> > -Wall). This is not the behavior I was expecting. How confused am I? >> > >> > I've distilled the behavior that's confusing me down to the following >> > example >> > >> > > module Test where >> > > >> > > class C a where f :: a -> () >> > >> > paired with a very silly plugin that always claims every constraint it >> sees >> > is a contradiction. >> > >> > > module Contrarian (plugin) where >> > > >> > > import Plugins (Plugin(..),defaultPlugin) >> > > import TcPluginM (tcPluginIO) >> > > import TcRnTypes (TcPlugin(..),TcPluginResult(TcPluginContradiction)) >> > > >> > > plugin :: Plugin >> > > plugin = defaultPlugin { tcPlugin = const (Just contrarianPlugin) } >> > > >> > > contrarianPlugin :: TcPlugin >> > > contrarianPlugin = TcPlugin { >> > > tcPluginInit = return () >> > > , >> > > tcPluginSolve = \() given derived wanted -> do >> > > tcPluginIO $ putStrLn "Alternative facts!" >> > > return $ TcPluginContradiction $ given ++ derived ++ wanted >> > > , >> > > tcPluginStop = \() -> return () >> > > } >> > >> > Please review the following GHCi session. We start *without* the plugin. >> > >> > $ ghc --interactive Test.hs >> > GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help >> > [1 of 1] Compiling Test ( Test.hs, interpreted ) >> > Ok, 1 module loaded. >> > *Test> f () >> > >> > :1:1: error: >> > * No instance for (C ()) arising from a use of `f' >> > * In the expression: f () >> > In an equation for `it': it = f () >> > >> > That behavior meets my expectations. Now let's add the plugin to see >> what >> > contradictions cause to happen --- my naive guess is that we should see >> the >> > same thing. (I don't really know what contradictions *should* cause GHC >> to >> > do *differently* than the above.) The following is a continuation of the >> > same session. >> > >> > *Test> :set -fplugin=Contrarian >> > *Test> f () >> > Alternative facts! >> > Alternative facts! >> > Alternative facts! >> > Alternative facts! >> > *** Exception: :3:1: error: >> > * No instance for (C ()) arising from a use of `f' >> > * In the expression: f () >> > In an equation for `it': it = f () >> > (deferred type error) >> > *Test> :t f >> > Alternative facts! >> > f :: a -> () >> > >> > Interesting: claiming the constraint is a contradiction seems to convert >> > the type error to a deferred type error. Let's see if we can disable >> that >> > (since it's not the behavior I want). >> > >> > *Test> :set -fno-defer-type-errors >> > *Test> :t f >> > Alternative facts! >> > f :: a -> () >> > *Test> f () >> > Alternative facts! >> > Alternative facts! >> > Alternative facts! >> > Alternative facts! >> > *** Exception: :3:1: error: >> > * No instance for (C ()) arising from a use of `f' >> > * In the expression: f () >> > In an equation for `it': it = f () >> > (deferred type error) >> > >> > :7:1: error: >> > * No instance for (Show (a0 -> ())) arising from a use of >> `print' >> > (maybe you haven't applied a function to enough arguments?) >> > * In a stmt of an interactive GHCi command: print it >> > *Test> >> > >> > I seems we can't disable this behavior. That makes it seem pretty >> > fundamental. So I'm guessing I'm confused about something, probably what >> > TcContradiction achieves in terms of the user experience. >> > >> > The behavior I want is for my plugin to identify (relevant) >> contradictions >> > and incur a static type error as soon as possible. I thought >> contradictions >> > would achieve that, but I seem to be wrong. >> > >> > What I should be expecting regarding contradictions? >> > >> > How should I achieve my desired behavior? Perhaps I should try "solving" >> > the contradiction constraints via an appeal to a TypeError constraint >> > instead. Or maybe I should just leave the identified contradictions >> > unsolved? >> > >> > Thanks. -Nick >> > >> > PS - A big thank you to Adam Gundry and Christiaan Baaij (and probably >> > others) for the useful wiki pages, blog posts, and publications -- >> they've >> > been a huge help for my learning about the typechecker via plugins! I'm >> > very excited about this plugin, and I hope to share it soon, but I'd >> like >> > to understand it better before I do. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh.najd at gmail.com Mon Aug 14 13:51:31 2017 From: sh.najd at gmail.com (Shayan Najd) Date: Mon, 14 Aug 2017 15:51:31 +0200 Subject: Failing Test Cases in HEAD Message-ID: In a freshly cloned GHC code base (c6462ab0...), in my system,`make test TEST="T13780c T13822"` fails. That is while `./validate` passes. I am rather new to GHC code base, and not so familiar with its build and testing system. So I was wondering whether this is an intended behaviour (e.g., some test cases are intentionally left out of `./validate`). Specifically, I follow the following steps: (1) `git clone --recursive git://git.haskell.org/ghc.git` (2) `cd ghc` (3) `cp mk/build.mk.sample mk/build.mk` (4) set `BuildFlavour = devel2` and then (5) ./boot (6) ./configure (7) make -j4 (8) make test TEST="T13780c T13822" I build in a variant of the docker image for GHC development on Linux (64 bit), if it matters. As it seems, Alan also gets the similar result on his system. I am investigating this, since my development of Growable ASTs is stalled due to some "GHC panic bug" when validating. (In my repo[1], I can successfully build with steps (2)-(7) above but `./validate` (and `make test TEST="T13780c T13822"`) fails) Thanks, Shayan [1] https://github.com/shayan-najd/GrowableGHC -------------- next part -------------- An HTML attachment was scrubbed... URL: From niteria at gmail.com Mon Aug 14 15:03:37 2017 From: niteria at gmail.com (Bartosz Nitka) Date: Mon, 14 Aug 2017 16:03:37 +0100 Subject: Failing Test Cases in HEAD In-Reply-To: References: Message-ID: `devel2` compiles GHC with extra assertions and `./validate` doesn't do that. There's `./validate --slow` that enables extra assertions. AFAIK harbormaster (and most ghc-devs) only does `./validate` which explains how failures like this can sneak in. We used to have a travis build that did `./validate --slow`, but it looks like travis currently fails at configure with: configure: error: GHC version 8.0 or later is required to compile GHC. Some more details here: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches Cheers, Bartosz 2017-08-14 14:51 GMT+01:00 Shayan Najd : > In a freshly cloned GHC code base (c6462ab0...), in my system,`make test > TEST="T13780c T13822"` fails. > That is while `./validate` passes. > > I am rather new to GHC code base, and not so familiar with its build and > testing system. > So I was wondering whether this is an intended behaviour (e.g., some test > cases are intentionally left out of `./validate`). > > Specifically, I follow the following steps: > (1) `git clone --recursive git://git.haskell.org/ghc.git` > (2) `cd ghc` > (3) `cp mk/build.mk.sample mk/build.mk` > (4) set `BuildFlavour = devel2` and then > (5) ./boot > (6) ./configure > (7) make -j4 > (8) make test TEST="T13780c T13822" > > I build in a variant of the docker image for GHC development on Linux (64 > bit), if it matters. > > As it seems, Alan also gets the similar result on his system. > > I am investigating this, since my development of Growable ASTs is stalled > due to some "GHC panic bug" when validating. > (In my repo[1], I can successfully build with steps (2)-(7) above but > `./validate` (and `make test TEST="T13780c T13822"`) fails) > > Thanks, > Shayan > > [1] https://github.com/shayan-najd/GrowableGHC > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From ggreif at gmail.com Wed Aug 16 18:04:27 2017 From: ggreif at gmail.com (Gabor Greif) Date: Wed, 16 Aug 2017 20:04:27 +0200 Subject: Stg-lint and bootstrapping (fails?) Message-ID: Hi all, I tried an stg-lint build thus: $ make V=1 GhcStage2HcOpts="-O1 -g -dstg-lint" ... and failed: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id base-4.10.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id rts -package-id ghc-prim-0.5.1.0 -package-id integer-gmp-1.0.1.0 -this-unit-id base -XHaskell2010 -O -dcore-lint -dno-debug-output -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./System/Mem/Weak.hs -o libraries/base/dist-install/build/System/Mem/Weak.o -dyno libraries/base/dist-install/build/System/Mem/Weak.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id base-4.10.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id rts -package-id ghc-prim-0.5.1.0 -package-id integer-gmp-1.0.1.0 -this-unit-id base -XHaskell2010 -O -dcore-lint -dno-debug-output -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./Control/Monad/IO/Class.hs -o libraries/base/dist-install/build/Control/Monad/IO/Class.o -dyno libraries/base/dist-install/build/Control/Monad/IO/Class.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.6.1.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O1 -g -dstg-lint -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/utils/Exception.hs -o compiler/stage2/build/Exception.o -dyno compiler/stage2/build/Exception.dyn_o /home/ggreif/%NoBackup%/ghc-head/libraries/base/dist-install/build/GHC/IO/Exception.hi Declaration for $fExceptionIOException4 Unfolding of $fExceptionIOException4: Failed to load interface for ?GHC.Fingerprint? There are files missing in the ?base-4.10.0.0? package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): kindPrimRep * -> * typePrimRep (m_as6 :: * -> *) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:344:5 in ghc:RepType kindPrimRep, called at compiler/simplStg/RepType.hs:305:18 in ghc:RepType typePrimRep, called at compiler/stgSyn/StgLint.hs:437:17 in ghc:StgLint Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> make[1]: *** [compiler/stage2/build/Exception.o] Error 1 make: *** [all] Error 2 What is the status of stg-lint? Is the above expected to happen? This is stock `master` branch as of today. Cheers, Gabor From ben at smart-cactus.org Wed Aug 16 19:27:41 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 16 Aug 2017 15:27:41 -0400 Subject: Stg-lint and bootstrapping (fails?) In-Reply-To: References: Message-ID: <87inhne2j6.fsf@ben-laptop.smart-cactus.org> Gabor Greif writes: > Hi all, > > I tried an stg-lint build thus: > How timely; just yesterday I looked at a number of stg lint issues after having noticed a number of issues with it over the past few months. I pushed patches for a number of issues (#14116, #14117, #14118) to Phabricator, but the bigger problem is #14120, which I don't yet have a compelling solution for (other than the "give up on catching all but the most trivial type errors" approach). Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ggreif at gmail.com Thu Aug 17 08:48:48 2017 From: ggreif at gmail.com (Gabor Greif) Date: Thu, 17 Aug 2017 10:48:48 +0200 Subject: Stg-lint and bootstrapping (fails?) In-Reply-To: <87inhne2j6.fsf@ben-laptop.smart-cactus.org> References: <87inhne2j6.fsf@ben-laptop.smart-cactus.org> Message-ID: Hi Ben, thanks for also looking into the issue! I am in the process of debugging a miscompilation related to #13861 (self-inflicted, hahahar), but without a working linter I am pretty much toast... I'll wait a bit more until your fixed hit master. Unrelated to linting, but seemingly related to "-g" I get a ton of warnings like this: WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akKa] Is this perhaps covered by your fixes? Cheers, Gabor On 8/16/17, Ben Gamari wrote: > Gabor Greif writes: > >> Hi all, >> >> I tried an stg-lint build thus: >> > How timely; just yesterday I looked at a number of stg lint issues after > having noticed a number of issues with it over the past few months. > I pushed patches for a number of issues (#14116, #14117, #14118) to > Phabricator, but the bigger problem is #14120, which I don't yet have a > compelling solution for (other than the "give up on catching all but the > most trivial type errors" approach). > > Cheers, > > - Ben > > From matthewtpickering at gmail.com Thu Aug 17 17:22:49 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 17 Aug 2017 18:22:49 +0100 Subject: Crossreferenced GHC 8.0.2 In-Reply-To: References: Message-ID: Hi all, If anyone is interested in this and using it further I have been working on two improvements. 1. A cross-referencer in the same style for the output of -ddump-simpl (which also links to the source code which produced the core). 2. A nix function which builds and references all dependencies. They are both found in my core-kythe repo with instructions about how to use them. https://github.com/mpickering/core-kythe You will need nix in order to use either of them but if you do it should be straightforward (albeit long in the first case!) I don't have a server to post examples to but Robin said he would when he got the chance. Matt On Tue, Jul 4, 2017 at 6:44 AM, Robin Palotai wrote: > FYI I added GHC 8.2.1-rc2 source to the index. Please tell if some source > you would be interested in is obviously missing. Thanks! > > 2017-06-30 22:41 GMT+02:00 Robin Palotai : >> >> Hello Matthew, >> >> Please see inline >> >> 2017-06-30 11:57 GMT+02:00 Matthew Pickering >> : >>> >>> Hi Robin, >>> >>> This looks really useful for developers. >>> >>> 1. Would it be possible to provide a script which allows developers to >>> build this index for themselves easily? >> >> >> First, build and install the `ghc_kythe_wrapper` (instructions at >> https://github.com/google/haskell-indexer). >> >> Then build GHC with `make`, and capture the build log. Here's the hacky >> script I used: >> https://gist.github.com/robinp/222cf3a39cc19178ec8691522056d7fe >> >> It filters the log and replaces GHC calls to call the wrapper, which emits >> Kythe entries. >> >> Finally run `serve.sh` of the repo to postprocess and serve the entries >> through HTTP. >> >> This is all pretty new, so feedback or questions welcome. If the method >> distills, could try to write a more formal guide. >> >>> >>> 2. Is it possible to use this tool to detect dead code? Functions >>> which are not used anywhere in the compiler. >> >> >> We'll get there eventually, but for now the emitted data is not >> fine-grained enough. The main missing piece is recording what are exported >> entities of a module (Kythe schema discussion in progress). Without this, >> unused locals (which anyway surface with -Wall) would be presented and >> noisy. >> >> Also, one would probably need to postprocess the data a bit for this, like >> loading into a graph database or other ways. >> >> Did you see https://github.com/ndmitchell/weeder by the way? Might work. >> >>> >>> 3. How are you pretty printing the output whilst retaining the source >>> formatting? I had a quick look at the source but I couldn't see where >>> the output was being produced. >>> >> >> The haskell-indexer-frontend-kythe emits Kythe (http://kythe.io) schema >> data. We just export the source offsets, and it's the Kythe postprocessing / >> serving pipeline that does all the formatting. >> >>> >>> Cheers, >>> >>> Matt >>> >>> On Fri, Jun 30, 2017 at 8:55 AM, Robin Palotai >>> wrote: >>> > Hello GHC devs, >>> > >>> > I ran haskell-indexer [1] on the GHC 8.0.2 tarball, partly because I >>> > find >>> > myself reading GHC source from time to time while working on the >>> > indexer, >>> > and partly since it's fun. >>> > >>> > First, here you can click around [2] and find where beloved functions >>> > are >>> > called from: >>> > >>> > http://stuff.codereview.me/#ghc/compiler/hsSyn/HsBinds.hs?corpus&signature >>> > (scroll down a bit, imports are not linked yet). >>> > >>> > Second, the way I indexed was pretty simple. I took the output of >>> > `make`, >>> > replaced the ghc used with the ghc_kythe_wrapper, and filtered the >>> > lines >>> > which included '-c', since I noticed that those duplicate previous >>> > large >>> > compile lines. This only indexes the stage1 compilation AFAIU. >>> > >>> > Feel free to suggest a better way to tap into the compilations to get >>> > everything properly indexed (and possibly only once). >>> > >>> > Any comments welcome! >>> > Robin >>> > >>> > [1]: https://github.com/google/haskell-indexer >>> > >>> > [2]: TLDR UI quirks: >>> > - Click the :: in top-left to navigate file tree >>> > - Ctrl-Click (on linux) to go directly to definition (otherwise click >>> > stuff from bottom pane) >>> > - Bottom pane often hides content, close it if stuck. >>> > >>> > _______________________________________________ >>> > ghc-devs mailing list >>> > ghc-devs at haskell.org >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> > >> >> > From simonpj at microsoft.com Fri Aug 18 10:25:52 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 18 Aug 2017 10:25:52 +0000 Subject: Alex install failure Message-ID: Friends I'm trying to update my installation of alex, on Unix (Ubuntu). But I get the dump below It's complaining about a lock file being an invalid argument (see highlight below). If I manually remove the file I get past that, it successfully installs tf-random, but the same thing happens on the next package. So I can install packages one at a time, but that's silly. Any ideas? Simon cabal install alex Resolving dependencies... Configuring tf-random-0.5... Building tf-random-0.5... Failed to install tf-random-0.5 Build log ( /home/simonpj/.cabal/logs/tf-random-0.5.log ): cabal: Entering directory '/tcabal mp/cabal-tmp-26141/tf-random-0.5' Configuring tf-random-0.5... Building tf-random-0.5... Preprocessing library tf-random-0.5... [1 of 4] Compiling System.Random.TF.Gen ( src/System/Random/TF/Gen.hs, dist/build/System/Random/TF/Gen.o ) [2 of 4] Compiling System.Random.TF.Init ( src/System/Random/TF/Init.hs, dist/build/System/Random/TF/Init.o ) src/System/Random/TF/Init.hs:94:5: warning: [-Wdeprecations] In the use of 'bitSize' (imported from Data.Bits): Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead" | 94 | | bitSize n > 64 = error "mkTFGen: case where size of Int > 64 not implemented" | ^^^^^^^ [3 of 4] Compiling System.Random.TF ( src/System/Random/TF.hs, dist/build/System/Random/TF.o ) [4 of 4] Compiling System.Random.TF.Instances ( src/System/Random/TF/Instances.hs, dist/build/System/Random/TF/Instances.o ) Creating package registration file: /tmp/pkgConf-tf-random-05965166491189641421.5 Installing library in /home/simonpj/.cabal/lib/x86_64-linux-ghc-8.2.1/tf-random-0.5-ABDhxe3mXYlHUEE5hzgewx Registering tf-random-0.5... cabal: '/usr/local/bin/ghc-pkg' exited with an error: ghc-pkg: Couldn't open database /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d for modification: {handle: /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d/package.cache.lock}: hLock: invalid argument (Bad file descriptor) cabal: Leaving directory '/tmp/cabal-tmp-26141/tf-random-0.5' cabal: Error: some packages failed to install: QuickCheck-2.10.0.1 depends on tf-random-0.5 which failed to install. alex-3.2.1 depends on tf-random-0.5 which failed to install. tf-random-0.5 failed during the final install step. The exception was: ExitFailure 1 simonpj at cam-05-unx:~/code/HEAD$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Aug 18 12:04:37 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 18 Aug 2017 08:04:37 -0400 Subject: Alex install failure In-Reply-To: References: Message-ID: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Friends > I'm trying to update my installation of alex, on Unix (Ubuntu). But I get the dump below > It's complaining about a lock file being an invalid argument (see highlight below). > If I manually remove the file I get past that, it successfully > installs tf-random, but the same thing happens on the next package. So > I can install packages one at a time, but that's silly. Hmm. Here's a shot in the dark: is home home directory mounted via NFS by any chance? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Fri Aug 18 14:05:40 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 18 Aug 2017 10:05:40 -0400 Subject: Stg-lint and bootstrapping (fails?) In-Reply-To: References: <87inhne2j6.fsf@ben-laptop.smart-cactus.org> Message-ID: <87efs9as3v.fsf@ben-laptop.smart-cactus.org> Gabor Greif writes: > Hi Ben, > > thanks for also looking into the issue! I am in the process of > debugging a miscompilation related to #13861 (self-inflicted, > hahahar), but without a working linter I am pretty much toast... I'll > wait a bit more until your fixed hit master. > If it helps I can give you a conservative "fix" which should at least allow the linter to pass valid code (at the expense of missing some bad programs). Ultimately this may be what we are focused to accept anyways. I'll discuss this with Simon next week. > Unrelated to linting, but seemingly related to "-g" I get a ton of > warnings like this: > > WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > OccurAnal failed to rediscover join point(s): [go58_akKa] > > Is this perhaps covered by your fixes? > I'm afraid not; this is the simplifier complaining that it lost track of a join point which should be solely an optimization. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From allbery.b at gmail.com Fri Aug 18 15:33:23 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 18 Aug 2017 11:33:23 -0400 Subject: Alex install failure In-Reply-To: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> Message-ID: On Fri, Aug 18, 2017 at 8:04 AM, Ben Gamari wrote: > Simon Peyton Jones via ghc-devs writes: > > I'm trying to update my installation of alex, on Unix (Ubuntu). But I > get the dump below > > It's complaining about a lock file being an invalid argument (see > highlight below). > > If I manually remove the file I get past that, it successfully > > installs tf-random, but the same thing happens on the next package. So > > I can install packages one at a time, but that's silly. > > Hmm. Here's a shot in the dark: is home home directory mounted via NFS > by any chance? > I was thinking CIFS, but pretty much the same issue. Or NTFS via FUSE module. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Aug 18 21:29:51 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 18 Aug 2017 21:29:51 +0000 Subject: Stg-lint and bootstrapping (fails?) In-Reply-To: References: <87inhne2j6.fsf@ben-laptop.smart-cactus.org> Message-ID: | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akKa] That shouldn't happen! If you can make a repro case, please open a ticket. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gabor | Greif | Sent: 17 August 2017 09:49 | To: Ben Gamari | Cc: ghc-devs | Subject: Re: Stg-lint and bootstrapping (fails?) | | [You don't often get email from GGREIF at GMAIL.COM. Learn why this is | important at http://aka.ms/LearnAboutSenderIdentification.] | | Hi Ben, | | thanks for also looking into the issue! I am in the process of debugging | a miscompilation related to #13861 (self-inflicted, hahahar), but without | a working linter I am pretty much toast... I'll wait a bit more until | your fixed hit master. | | Unrelated to linting, but seemingly related to "-g" I get a ton of | warnings like this: | | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akKa] | | Is this perhaps covered by your fixes? | | Cheers, | | Gabor | | On 8/16/17, Ben Gamari wrote: | > Gabor Greif writes: | > | >> Hi all, | >> | >> I tried an stg-lint build thus: | >> | > How timely; just yesterday I looked at a number of stg lint issues | > after having noticed a number of issues with it over the past few | months. | > I pushed patches for a number of issues (#14116, #14117, #14118) to | > Phabricator, but the bigger problem is #14120, which I don't yet have | > a compelling solution for (other than the "give up on catching all but | > the most trivial type errors" approach). | > | > Cheers, | > | > - Ben | > | > | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C057084a514e548c9642c08d4e54 | cd776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636385565585443027&sda | ta=2NNSmwZJv0czL4BykKENAWW38sUhYHF7IYyXscAfHdw%3D&reserved=0 From m at tweag.io Fri Aug 18 21:38:33 2017 From: m at tweag.io (Boespflug, Mathieu) Date: Fri, 18 Aug 2017 23:38:33 +0200 Subject: Where to discuss the linear types extension of GHC? In-Reply-To: <1503089740.31595.21.camel@jeltsch.info> References: <1499890549.12635.22.camel@jeltsch.info> <1499897665.12635.38.camel@jeltsch.info> <1503089740.31595.21.camel@jeltsch.info> Message-ID: Hi Wolfgang, great to see interest in linear types! I would advise caution about building anything on top of the linear types extension at this time. If you have interesting use cases, however, do tell, so that these use cases can influence the design. This is pre-alpha software, meaning that it's not even good enough as a developer preview of all the basic features. It's an in-progress development branch, which is going to take time to stabilize. Furthermore, whether the feature makes it into GHC will depend on what the GHC proposals committee thinks about it. The current authors of the would-be extension have yet to draft a proposal and submit it to the committee. If we manage to write a proposal in time, based on a beta level implementation of linear types, and if the committee accepts the proposal, then maybe the feature can make it into GHC 8.4. Or in GHC 8.6. That's our hope, at any rate. But it could also be never, if the committee rejects the proposal... Best, -- Mathieu Boespflug Founder at http://tweag.io. On 18 August 2017 at 22:55, Wolfgang Jeltsch wrote: > Hi! > > I just read through the README. According to it, there are several crucial > things not implemented yet (case and let come to my mind), and there are > some fundamental bugs (which make it very easy to circumvent linearity > checks, making the whole extension pointless). Is the situation still like > this? > > What are your honest expectations regarding the future development of the > linear types feature and its integration into the official GHC? Is it > realistic to hope for this feature to be available in a stable GHC version > withing, say, the next 12 months? I would like to use linearity in some > project of mine, but at the moment, I am unsure whether it is really a good > idea to rely on this feature becoming available. > > All the best, > Wolfgang > > Am Mittwoch, den 19.07.2017, 08:52 +0000 schrieb Edvard Hübinette: > > Hi Wolfgang, > > the updated README is live and can be found here > ! > > Cheers, > Edvard > > On Thu, 13 Jul 2017 at 17:54 Spiwack, Arnaud > wrote: > > I think the answer to both questions can be the same: the github issue of > Tweag's ghc repo: https://github.com/tweag/ghc/issues . > > Regarding this particular bug: it is a known bug indeed. I'll be fixing it > soon. We're expanding the README to include known bugs and usage > instruction. > > Thanks a lot for your time and interest, > Arnaud > > On Thu, Jul 13, 2017 at 12:14 AM, Wolfgang Jeltsch < > wolfgang-it at jeltsch.info> wrote: > > Hi! > > Another question is where to submit bugs. I already found the first one 😉: > > GHCi> let dup :: a -> (a, a); dup x = (x, x) > > GHCi> let unsafeDup :: a ⊸ (a, a); unsafeDup = dup > > GHCi> :type unsafeDup > > unsafeDup :: a ⊸ (a, a) > > GHCi> unsafeDup True > > (True,True) > > > All the best, > Wolfgang > > Am Mittwoch, den 12.07.2017, 23:15 +0300 schrieb Wolfgang Jeltsch: > > Hi! > > I think I will have several questions about the linear types extension > when trying to use it in the near future. Furthermore, I also want to give > feedback on the design of this extension. What is the appropriate forum for > discussing the linear types extension? The GHC developers mailing list > might be an option. However, I think that it would be better to contact you > more directly regarding these matters. Is there some issue tracker or > discussion platform I should use? > > All the best, > Wolfgang > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Aug 18 22:42:49 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 18 Aug 2017 22:42:49 +0000 Subject: Alex install failure In-Reply-To: References: Message-ID: That's what I did. It then succeeds in installing one package, and fails in the same way on the next one. So I can install packages one at a time, by deleting the lock file manually each time. Bizarre. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 18 August 2017 11:59 | To: Simon Peyton Jones | Subject: Re: Alex install failure | | Try removing | | /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d/package.cache.lock | | | | On Fri, Aug 18, 2017 at 12:25 PM, Simon Peyton Jones via ghc-devs wrote: | > Friends | > | > I’m trying to update my installation of alex, on Unix (Ubuntu). But I | > get the dump below | > | > It’s complaining about a lock file being an invalid argument (see | > highlight below). | > | > If I manually remove the file I get past that, it successfully | > installs tf-random, but the same thing happens on the next package. | > So I can install packages one at a time, but that’s silly. | > | > Any ideas? | > | > Simon | > | > | > | > cabal install alex | > | > Resolving dependencies... | > | > Configuring tf-random-0.5... | > | > Building tf-random-0.5... | > | > Failed to install tf-random-0.5 | > | > Build log ( /home/simonpj/.cabal/logs/tf-random-0.5.log ): | > | > cabal: Entering directory '/tcabal mp/cabal-tmp-26141/tf-random-0.5' | > | > Configuring tf-random-0.5... | > | > Building tf-random-0.5... | > | > Preprocessing library tf-random-0.5... | > | > [1 of 4] Compiling System.Random.TF.Gen ( src/System/Random/TF/Gen.hs, | > dist/build/System/Random/TF/Gen.o ) | > | > [2 of 4] Compiling System.Random.TF.Init ( | > src/System/Random/TF/Init.hs, dist/build/System/Random/TF/Init.o ) | > | > | > | > src/System/Random/TF/Init.hs:94:5: warning: [-Wdeprecations] | > | > In the use of ‘bitSize’ (imported from Data.Bits): | > | > Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead" | > | > | | > | > 94 | | bitSize n > 64 = error "mkTFGen: case where size of Int > 64 | not | > implemented" | > | > | ^^^^^^^ | > | > [3 of 4] Compiling System.Random.TF ( src/System/Random/TF.hs, | > dist/build/System/Random/TF.o ) | > | > [4 of 4] Compiling System.Random.TF.Instances ( | > src/System/Random/TF/Instances.hs, | > dist/build/System/Random/TF/Instances.o ) | > | > Creating package registration file: | > | > /tmp/pkgConf-tf-random-05965166491189641421.5 | > | > Installing library in | > | > /home/simonpj/.cabal/lib/x86_64-linux-ghc-8.2.1/tf-random-0.5-ABDhxe3m | > XYlHUEE5hzgewx | > | > Registering tf-random-0.5... | > | > cabal: '/usr/local/bin/ghc-pkg' exited with an error: | > | > ghc-pkg: Couldn't open database | > | > /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d for modification: | > | > {handle: | > | > /home/simonpj/.ghc/x86_64-linux- | 8.2.1/package.conf.d/package.cache.lock}: | > | > hLock: invalid argument (Bad file descriptor) | > | > cabal: Leaving directory '/tmp/cabal-tmp-26141/tf-random-0.5' | > | > cabal: Error: some packages failed to install: | > | > QuickCheck-2.10.0.1 depends on tf-random-0.5 which failed to install. | > | > alex-3.2.1 depends on tf-random-0.5 which failed to install. | > | > tf-random-0.5 failed during the final install step. The exception was: | > | > ExitFailure 1 | > | > simonpj at cam-05-unx:~/code/HEAD$ | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C3f6ad797e3454147fa5e08d4e62 | 821e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636386507413664213&sda | ta=ex4vc7sfwhYQsoTNUKSrtdKZtIkDxDWor0CEKN0M4Wk%3D&reserved=0 | > From simonpj at microsoft.com Fri Aug 18 22:43:27 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 18 Aug 2017 22:43:27 +0000 Subject: Alex install failure In-Reply-To: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> Message-ID: | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by | any chance? Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. So what? Simon | -----Original Message----- | From: Ben Gamari [mailto:ben at smart-cactus.org] | Sent: 18 August 2017 13:05 | To: Simon Peyton Jones ; ghc-devs | Subject: Re: Alex install failure | | Simon Peyton Jones via ghc-devs writes: | | > Friends | > I'm trying to update my installation of alex, on Unix (Ubuntu). But I | > get the dump below It's complaining about a lock file being an invalid | argument (see highlight below). | > If I manually remove the file I get past that, it successfully | > installs tf-random, but the same thing happens on the next package. So | > I can install packages one at a time, but that's silly. | | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by | any chance? | | Cheers, | | - Ben From simonpj at microsoft.com Fri Aug 18 22:52:41 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 18 Aug 2017 22:52:41 +0000 Subject: Where to discuss the linear types extension of GHC? In-Reply-To: References: <1499890549.12635.22.camel@jeltsch.info> <1499897665.12635.38.camel@jeltsch.info> <1503089740.31595.21.camel@jeltsch.info> Message-ID: But it could also be never, if the committee rejects the proposal... Don’t let that put you off. The more numerous and compelling the applications, the more likely it is that the committee will accept it! It’s a Big Feature, so the bar is high. But if there is a diverse bunch of actual users saying “this will make our lives much better, and here’s how” the case becomes much stronger. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Boespflug, Mathieu Sent: 18 August 2017 22:39 To: Wolfgang Jeltsch Cc: ghc-devs ; Edvard Hübinette Subject: Re: Where to discuss the linear types extension of GHC? You don't often get email from M at TWEAG.IO, which appears similar to someone who has previously sent you email, but may not be that person. Learn why this may be a problem Feedback Hi Wolfgang, great to see interest in linear types! I would advise caution about building anything on top of the linear types extension at this time. If you have interesting use cases, however, do tell, so that these use cases can influence the design. This is pre-alpha software, meaning that it's not even good enough as a developer preview of all the basic features. It's an in-progress development branch, which is going to take time to stabilize. Furthermore, whether the feature makes it into GHC will depend on what the GHC proposals committee thinks about it. The current authors of the would-be extension have yet to draft a proposal and submit it to the committee. If we manage to write a proposal in time, based on a beta level implementation of linear types, and if the committee accepts the proposal, then maybe the feature can make it into GHC 8.4. Or in GHC 8.6. That's our hope, at any rate. But it could also be never, if the committee rejects the proposal... Best, -- Mathieu Boespflug Founder at http://tweag.io. On 18 August 2017 at 22:55, Wolfgang Jeltsch > wrote: Hi! I just read through the README. According to it, there are several crucial things not implemented yet (case and let come to my mind), and there are some fundamental bugs (which make it very easy to circumvent linearity checks, making the whole extension pointless). Is the situation still like this? What are your honest expectations regarding the future development of the linear types feature and its integration into the official GHC? Is it realistic to hope for this feature to be available in a stable GHC version withing, say, the next 12 months? I would like to use linearity in some project of mine, but at the moment, I am unsure whether it is really a good idea to rely on this feature becoming available. All the best, Wolfgang Am Mittwoch, den 19.07.2017, 08:52 +0000 schrieb Edvard Hübinette: Hi Wolfgang, the updated README is live and can be found here! Cheers, Edvard On Thu, 13 Jul 2017 at 17:54 Spiwack, Arnaud > wrote: I think the answer to both questions can be the same: the github issue of Tweag's ghc repo: https://github.com/tweag/ghc/issues . Regarding this particular bug: it is a known bug indeed. I'll be fixing it soon. We're expanding the README to include known bugs and usage instruction. Thanks a lot for your time and interest, Arnaud On Thu, Jul 13, 2017 at 12:14 AM, Wolfgang Jeltsch > wrote: Hi! Another question is where to submit bugs. I already found the first one 😉: GHCi> let dup :: a -> (a, a); dup x = (x, x) GHCi> let unsafeDup :: a ⊸ (a, a); unsafeDup = dup GHCi> :type unsafeDup unsafeDup :: a ⊸ (a, a) GHCi> unsafeDup True (True,True) All the best, Wolfgang Am Mittwoch, den 12.07.2017, 23:15 +0300 schrieb Wolfgang Jeltsch: Hi! I think I will have several questions about the linear types extension when trying to use it in the near future. Furthermore, I also want to give feedback on the design of this extension. What is the appropriate forum for discussing the linear types extension? The GHC developers mailing list might be an option. However, I think that it would be better to contact you more directly regarding these matters. Is there some issue tracker or discussion platform I should use? All the best, Wolfgang -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Fri Aug 18 22:52:56 2017 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 19 Aug 2017 00:52:56 +0200 Subject: Alex install failure In-Reply-To: References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> Message-ID: On Sat, Aug 19, 2017 at 12:43 AM, Simon Peyton Jones via ghc-devs wrote: > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. So what? Then you're another victim of https://ghc.haskell.org/trac/ghc/ticket/13945 :-/ From simonpj at microsoft.com Fri Aug 18 22:59:14 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 18 Aug 2017 22:59:14 +0000 Subject: Alex install failure In-Reply-To: References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> Message-ID: | Then you're another victim of | | https://ghc.haskell.org/trac/ghc/ticket/13945 [Reads ticket]. Blimey. This looks serious. As in release-blocker (except that we have released). Why does it only happen with 8.2.1? The ticket has no how-to-fix plan. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 18 August 2017 23:53 | To: Simon Peyton Jones | Cc: Ben Gamari ; ghc-devs | Subject: Re: Alex install failure | | On Sat, Aug 19, 2017 at 12:43 AM, Simon Peyton Jones via ghc-devs wrote: | > | Hmm. Here's a shot in the dark: is home home directory mounted via | > | NFS by any chance? | > | > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. | So what? | | Then you're another victim of | | https://ghc.haskell.org/trac/ghc/ticket/13945 | | :-/ From me at ara.io Fri Aug 18 23:07:28 2017 From: me at ara.io (Ara Adkins) Date: Sat, 19 Aug 2017 00:07:28 +0100 Subject: Alex install failure Message-ID: NFS can be pretty dodgy with transient files due to latency. Sometimes the delete takes appreciable time after the command is issued so the lock file might just be persisting. I’d try installing into a cabal sandbox on a local drive and see if the same issue crops up. _ara > On 18 Aug 2017, at 23:43, Simon Peyton Jones wrote: > > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. So what? > > Simon > > | -----Original Message----- > | From: Ben Gamari [mailto:ben at smart-cactus.org] > | Sent: 18 August 2017 13:05 > | To: Simon Peyton Jones ; ghc-devs | devs at haskell.org> > | Subject: Re: Alex install failure > | > | Simon Peyton Jones via ghc-devs writes: > | > | > Friends > | > I'm trying to update my installation of alex, on Unix (Ubuntu). But I > | > get the dump below It's complaining about a lock file being an invalid > | argument (see highlight below). > | > If I manually remove the file I get past that, it successfully > | > installs tf-random, but the same thing happens on the next package. So > | > I can install packages one at a time, but that's silly. > | > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > | > | Cheers, > | > | - Ben > > From simonpj at microsoft.com Fri Aug 18 23:37:32 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 18 Aug 2017 23:37:32 +0000 Subject: Alex install failure In-Reply-To: References: Message-ID: Maybe so, but it's really not a good experience for GHC/Cabal users. If aptget did this, people would bleat loudly. Simon | -----Original Message----- | From: Ara Adkins [mailto:me at ara.io] | Sent: 19 August 2017 00:07 | To: Simon Peyton Jones | Cc: Ben Gamari ; ghc-devs | Subject: Re: Alex install failure | | [You don't often get email from ME at ARA.IO. Learn why this is important at | http://aka.ms/LearnAboutSenderIdentification.] | | NFS can be pretty dodgy with transient files due to latency. Sometimes | the delete takes appreciable time after the command is issued so the lock | file might just be persisting. I’d try installing into a cabal sandbox on | a local drive and see if the same issue crops up. | | _ara | | > On 18 Aug 2017, at 23:43, Simon Peyton Jones | wrote: | > | > | Hmm. Here's a shot in the dark: is home home directory mounted via | > | NFS by any chance? | > | > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. | So what? | > | > Simon | > | > | -----Original Message----- | > | From: Ben Gamari [mailto:ben at smart-cactus.org] | > | Sent: 18 August 2017 13:05 | > | To: Simon Peyton Jones ; ghc-devs | devs at haskell.org> | > | Subject: Re: Alex install failure | > | | > | Simon Peyton Jones via ghc-devs writes: | > | | > | > Friends | > | > I'm trying to update my installation of alex, on Unix (Ubuntu). | > | > But I get the dump below It's complaining about a lock file being | > | > an invalid | > | argument (see highlight below). | > | > If I manually remove the file I get past that, it successfully | > | > installs tf-random, but the same thing happens on the next | > | > package. So I can install packages one at a time, but that's silly. | > | | > | Hmm. Here's a shot in the dark: is home home directory mounted via | > | NFS by any chance? | > | | > | Cheers, | > | | > | - Ben | > | > From me at ara.io Sat Aug 19 00:07:04 2017 From: me at ara.io (Ara Adkins) Date: Sat, 19 Aug 2017 01:07:04 +0100 Subject: Alex install failure In-Reply-To: References: Message-ID: <6C0EC5AC-5C91-4879-B55E-F1E0127BDAF8@ara.io> I don’t disagree in the slightest! It’s just an easy way to find out if that is the cause of what you’re seeing or if it’s something deeper. For what it’s worth I’ve tried to replicate this on NFS to no avail, but it’s not like the mount I was using was under much load. _ara > On 19 Aug 2017, at 00:37, Simon Peyton Jones wrote: > > Maybe so, but it's really not a good experience for GHC/Cabal users. If aptget did this, people would bleat loudly. > > Simon > > | -----Original Message----- > | From: Ara Adkins [mailto:me at ara.io] > | Sent: 19 August 2017 00:07 > | To: Simon Peyton Jones > | Cc: Ben Gamari ; ghc-devs > | Subject: Re: Alex install failure > | > | [You don't often get email from ME at ARA.IO. Learn why this is important at > | http://aka.ms/LearnAboutSenderIdentification.] > | > | NFS can be pretty dodgy with transient files due to latency. Sometimes > | the delete takes appreciable time after the command is issued so the lock > | file might just be persisting. I’d try installing into a cabal sandbox on > | a local drive and see if the same issue crops up. > | > | _ara > | > | > On 18 Aug 2017, at 23:43, Simon Peyton Jones > | wrote: > | > > | > | Hmm. Here's a shot in the dark: is home home directory mounted via > | > | NFS by any chance? > | > > | > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. > | So what? > | > > | > Simon > | > > | > | -----Original Message----- > | > | From: Ben Gamari [mailto:ben at smart-cactus.org] > | > | Sent: 18 August 2017 13:05 > | > | To: Simon Peyton Jones ; ghc-devs | > | devs at haskell.org> > | > | Subject: Re: Alex install failure > | > | > | > | Simon Peyton Jones via ghc-devs writes: > | > | > | > | > Friends > | > | > I'm trying to update my installation of alex, on Unix (Ubuntu). > | > | > But I get the dump below It's complaining about a lock file being > | > | > an invalid > | > | argument (see highlight below). > | > | > If I manually remove the file I get past that, it successfully > | > | > installs tf-random, but the same thing happens on the next > | > | > package. So I can install packages one at a time, but that's silly. > | > | > | > | Hmm. Here's a shot in the dark: is home home directory mounted via > | > | NFS by any chance? > | > | > | > | Cheers, > | > | > | > | - Ben > | > > | > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Sat Aug 19 02:56:18 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 18 Aug 2017 22:56:18 -0400 Subject: Phab: conditional approval Message-ID: <95D2EA45-B7A1-497E-B174-2D8037054C36@cs.brynmawr.edu> Hi devs, When reviewing a diff on Phab, I can "accept" or "request changes". Sometimes, though, I want to do both: I suggest very minor (e.g., typo) changes, but then when these changes are made, I accept. I'm leery of making the suggestions and saying "accept", because then someone working quickly may merge without noticing the typos. Does Phab have such an option? Thanks, Richard From fw at deneb.enyo.de Sat Aug 19 08:34:56 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 19 Aug 2017 10:34:56 +0200 Subject: New primitive types? In-Reply-To: (Michal Terepeta's message of "Wed, 02 Aug 2017 18:52:50 +0000") References: Message-ID: <87k220rm4v.fsf@mid.deneb.enyo.de> * Michal Terepeta: > On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald > wrote: >> One issue with packed fields is that on many architectures you can't > quite do subword reads or >> writes. So it might not always be a win. > > Could you give any examples? Historic DEC Alpha, now long obsolete. It is very hard to create compliant and performant implementations of Java 5, C 11 or C++ 11 on such architectures. All these languages (and their subsequent revisions) require that naturally aligned objects can be accessed independently. For example, you can't use a simple read-modify-write cycle to implement a single-byte store using word operations. That's why such architectures really do not have a future (or even a present), except maybe in niche markets such as GPGPU (but even there, things are heading towards the de-facto standard memory model). From ben at smart-cactus.org Sat Aug 19 15:30:29 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 19 Aug 2017 11:30:29 -0400 Subject: Alex install failure In-Reply-To: References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> Message-ID: <8760djbmne.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones writes: > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. So what? > Well, as others have pointed out NFS and locking tends to be a bit of a can of worms. Some broken systems don't even run the locking daemon by default; even when configured properly locking can still be problematic, especially under contention (although I doubt this is the case in your situation). It's been quite a while since I have configured NFS, but IIRC one thing to verify is that there is at least one lockd process and one portmapper process running. I doubt this is problematic under Ubuntu in 2017, but it's worth checking. It might also be a good idea to grab an strace log of ghc-pkg to see what precisely is going on. Perhaps also check the system log. Regardless, we should try getting to the bottom of this; ghc-pkg failing is quite bad, even if the system's locking configuration happens to be broken. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Sat Aug 19 15:44:46 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 19 Aug 2017 11:44:46 -0400 Subject: Alex install failure In-Reply-To: References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> Message-ID: <87378nblzl.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones writes: > | Then you're another victim of > | > | https://ghc.haskell.org/trac/ghc/ticket/13945 > Oh dear, yes, it looks like I lost track of this one. > [Reads ticket]. Blimey. This looks serious. As in release-blocker > (except that we have released). Why does it only happen with 8.2.1? > The ticket has no how-to-fix plan. > The problem is that we don't really know what the issue is yet. Some have hypothesized that it's due to SELinux, I suspect the problem is NFS. Perhaps there are multiple issues. More information about the environments under which this is observed would certainly be helpful. If someone could describe their environment I would be happy to try reproducing and investigate. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Sat Aug 19 15:54:18 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 19 Aug 2017 11:54:18 -0400 Subject: Stg-lint and bootstrapping (fails?) In-Reply-To: References: <87inhne2j6.fsf@ben-laptop.smart-cactus.org> Message-ID: <87ziava6z9.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones writes: > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akKa] > > That shouldn't happen! If you can make a repro case, please open a ticket. > Oh dear, then I've really misunderstood the intent of this warning. I've been noticing these during the GHC build for quite some time now. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From palotai.robin at gmail.com Sun Aug 20 15:23:50 2017 From: palotai.robin at gmail.com (Robin Palotai) Date: Sun, 20 Aug 2017 17:23:50 +0200 Subject: Crossreferenced GHC 8.0.2 In-Reply-To: References: Message-ID: Sorry for the delay - added it, see for example http://stuff.codereview.me/#../logs/Control.Monad.Skeleton.core?corpus=core-kythe&signature&line=41 . Note that the Haskell sources (reachable by following the 'generates' reverse edge from the Core) seem to have the empty corpus (for example http://stuff.codereview.me/#F.hs?corpus&signature&line=1). (Also, one of the example entries had a serialization error, omitted that one). Looks interesting! 2017-08-17 19:22 GMT+02:00 Matthew Pickering : > Hi all, > > If anyone is interested in this and using it further I have been > working on two improvements. > > 1. A cross-referencer in the same style for the output of -ddump-simpl > (which also links to the source code which produced the core). > > 2. A nix function which builds and references all dependencies. > > They are both found in my core-kythe repo with instructions about how > to use them. > > https://github.com/mpickering/core-kythe > > You will need nix in order to use either of them but if you do it > should be straightforward (albeit long in the first case!) > > I don't have a server to post examples to but Robin said he would when > he got the chance. > > Matt > > > On Tue, Jul 4, 2017 at 6:44 AM, Robin Palotai > wrote: > > FYI I added GHC 8.2.1-rc2 source to the index. Please tell if some source > > you would be interested in is obviously missing. Thanks! > > > > 2017-06-30 22:41 GMT+02:00 Robin Palotai : > >> > >> Hello Matthew, > >> > >> Please see inline > >> > >> 2017-06-30 11:57 GMT+02:00 Matthew Pickering > >> : > >>> > >>> Hi Robin, > >>> > >>> This looks really useful for developers. > >>> > >>> 1. Would it be possible to provide a script which allows developers to > >>> build this index for themselves easily? > >> > >> > >> First, build and install the `ghc_kythe_wrapper` (instructions at > >> https://github.com/google/haskell-indexer). > >> > >> Then build GHC with `make`, and capture the build log. Here's the hacky > >> script I used: > >> https://gist.github.com/robinp/222cf3a39cc19178ec8691522056d7fe > >> > >> It filters the log and replaces GHC calls to call the wrapper, which > emits > >> Kythe entries. > >> > >> Finally run `serve.sh` of the repo to postprocess and serve the entries > >> through HTTP. > >> > >> This is all pretty new, so feedback or questions welcome. If the method > >> distills, could try to write a more formal guide. > >> > >>> > >>> 2. Is it possible to use this tool to detect dead code? Functions > >>> which are not used anywhere in the compiler. > >> > >> > >> We'll get there eventually, but for now the emitted data is not > >> fine-grained enough. The main missing piece is recording what are > exported > >> entities of a module (Kythe schema discussion in progress). Without > this, > >> unused locals (which anyway surface with -Wall) would be presented and > >> noisy. > >> > >> Also, one would probably need to postprocess the data a bit for this, > like > >> loading into a graph database or other ways. > >> > >> Did you see https://github.com/ndmitchell/weeder by the way? Might > work. > >> > >>> > >>> 3. How are you pretty printing the output whilst retaining the source > >>> formatting? I had a quick look at the source but I couldn't see where > >>> the output was being produced. > >>> > >> > >> The haskell-indexer-frontend-kythe emits Kythe (http://kythe.io) schema > >> data. We just export the source offsets, and it's the Kythe > postprocessing / > >> serving pipeline that does all the formatting. > >> > >>> > >>> Cheers, > >>> > >>> Matt > >>> > >>> On Fri, Jun 30, 2017 at 8:55 AM, Robin Palotai < > palotai.robin at gmail.com> > >>> wrote: > >>> > Hello GHC devs, > >>> > > >>> > I ran haskell-indexer [1] on the GHC 8.0.2 tarball, partly because I > >>> > find > >>> > myself reading GHC source from time to time while working on the > >>> > indexer, > >>> > and partly since it's fun. > >>> > > >>> > First, here you can click around [2] and find where beloved functions > >>> > are > >>> > called from: > >>> > > >>> > http://stuff.codereview.me/#ghc/compiler/hsSyn/HsBinds.hs? > corpus&signature > >>> > (scroll down a bit, imports are not linked yet). > >>> > > >>> > Second, the way I indexed was pretty simple. I took the output of > >>> > `make`, > >>> > replaced the ghc used with the ghc_kythe_wrapper, and filtered the > >>> > lines > >>> > which included '-c', since I noticed that those duplicate previous > >>> > large > >>> > compile lines. This only indexes the stage1 compilation AFAIU. > >>> > > >>> > Feel free to suggest a better way to tap into the compilations to get > >>> > everything properly indexed (and possibly only once). > >>> > > >>> > Any comments welcome! > >>> > Robin > >>> > > >>> > [1]: https://github.com/google/haskell-indexer > >>> > > >>> > [2]: TLDR UI quirks: > >>> > - Click the :: in top-left to navigate file tree > >>> > - Ctrl-Click (on linux) to go directly to definition (otherwise > click > >>> > stuff from bottom pane) > >>> > - Bottom pane often hides content, close it if stuck. > >>> > > >>> > _______________________________________________ > >>> > ghc-devs mailing list > >>> > ghc-devs at haskell.org > >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >>> > > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Aug 20 16:11:33 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 20 Aug 2017 18:11:33 +0200 Subject: Disabling Travis? Message-ID: <1503245493.4020.2.camel@joachim-breitner.de> Hi, I wasn’t looking for a while I notice that the travis CI build of GHC has not been succeeding for two months, partly because build time exceeded the already much extended limits we have, partly because support for booting with 7.10 was dropped, but the .travis file was not used. A CI system that is not normally succeeding is pretty pointless, and will only confuse people who submit pull requests over GitHub who see failures. So if noone complains now I will soon disable building on Travis. Greetings, Joachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de https://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rae at cs.brynmawr.edu Mon Aug 21 03:55:21 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sun, 20 Aug 2017 23:55:21 -0400 Subject: Disabling Travis? In-Reply-To: <1503245493.4020.2.camel@joachim-breitner.de> References: <1503245493.4020.2.camel@joachim-breitner.de> Message-ID: <7920340D-2B0B-426E-8960-8A391AA46689@cs.brynmawr.edu> Indeed I wrote and then deleted an email to you asking to update the Travis script to work again. I deleted it because I realized that fixing this myself was easy. So, at least one person cares about Travis. :) Why do I care? Because I find it easier to validate with Travis than with Phab, for these reasons: - I don't have to go through the process of creating a new diff -- no arc, no diff #, no reviewers that I don't care for (as I just want validation). - Phab does advanced Sorcerer's-apprentice-level wizardry in applying my patch. If it's not rebased to a current master, Strange Things happen. And sometimes, I'm not ready to rebase (as I just want validation). One might ask these questions at this point: Q: Shouldn't I *always* create a diff for a change I'm making? A: Perhaps I should. But sometimes a fix is very straightforward and I simply don't have the cycles to go through a review process for every patch. As any committer has learned, SPJ reviews every commit that goes by anyway, and it seems more agile just to commit what seem like simple patches and then commit tweaks. Q: Why don't I just validate locally? A: Because I'm on a Mac laptop. There are frequently tests that fail on Mac that aren't my fault, and sometimes I'm about to need to move the laptop -- and I don't want this to interrupt validation. The big minus to Travis, as I see it, are that only committers can use it. (A forked repo just doesn't work because of the way that submodules are checked out, IIRC.) This minus doesn't affect me, however. Thanks, Richard > On Aug 20, 2017, at 12:11 PM, Joachim Breitner wrote: > > Hi, > > I wasn’t looking for a while I notice that the travis CI build of GHC > has not been succeeding for two months, partly because build time > exceeded the already much extended limits we have, partly because > support for booting with 7.10 was dropped, but the .travis file was not > used. > > A CI system that is not normally succeeding is pretty pointless, and > will only confuse people who submit pull requests over GitHub who see > failures. > > So if noone complains now I will soon disable building on Travis. > > Greetings, > Joachim > > > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de > https://www.joachim-breitner.de/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Mon Aug 21 07:54:25 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 21 Aug 2017 09:54:25 +0200 Subject: Disabling Travis? In-Reply-To: <7920340D-2B0B-426E-8960-8A391AA46689@cs.brynmawr.edu> References: <1503245493.4020.2.camel@joachim-breitner.de> <7920340D-2B0B-426E-8960-8A391AA46689@cs.brynmawr.edu> Message-ID: <1503302065.29178.1.camel@joachim-breitner.de> Hi, Am Sonntag, den 20.08.2017, 23:55 -0400 schrieb Richard Eisenberg: > The big minus to Travis, as I see it, are that only committers can > use it. (A forked repo just doesn't work because of the way that > submodules are checked out, IIRC.) This minus doesn't affect me, > however. I think the biggest minus is that Travis can either be configured to send mails to one specific address (as it was initially, when I received all the mail and could check whether I want to notify the author), or to the author of the patch, but not both. Currently it is sent to notify the author, but people seem to simply ignore the mails.  (Or maybe even only authors who also registered on travis get them?) So if there is demand to keep using Travis, maybe we have to go back to sending notification mails to one person who oversees this service? Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Mon Aug 21 15:49:45 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 21 Aug 2017 15:49:45 +0000 Subject: Stg-lint and bootstrapping (fails?) In-Reply-To: <87ziava6z9.fsf@ben-laptop.smart-cactus.org> References: <87inhne2j6.fsf@ben-laptop.smart-cactus.org> <87ziava6z9.fsf@ben-laptop.smart-cactus.org> Message-ID: | Oh dear, then I've really misunderstood the intent of this warning. I've | been noticing these during the GHC build for quite some time now. Really? After stumbling on #14142, I removed -dno-debug-output from mk/flavours/validate.mk and re-validated. Not a single occurrence of | > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | > | OccurAnal failed to rediscover join point(s): [go58_akKa] How can I reproduce what you are seeing? Simon | -----Original Message----- | From: Ben Gamari [mailto:ben at smart-cactus.org] | Sent: 19 August 2017 16:54 | To: Simon Peyton Jones ; Gabor Greif | | Cc: ghc-devs | Subject: RE: Stg-lint and bootstrapping (fails?) | | Simon Peyton Jones writes: | | > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | > | OccurAnal failed to rediscover join point(s): [go58_akKa] | > | > That shouldn't happen! If you can make a repro case, please open a | ticket. | > | Oh dear, then I've really misunderstood the intent of this warning. I've | been noticing these during the GHC build for quite some time now. | | Cheers, | | - Ben From ggreif at gmail.com Mon Aug 21 18:21:30 2017 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 21 Aug 2017 18:21:30 +0000 Subject: Stg-lint and bootstrapping (fails?) In-Reply-To: References: <87inhne2j6.fsf@ben-laptop.smart-cactus.org> <87ziava6z9.fsf@ben-laptop.smart-cactus.org> Message-ID: Hi Simon, for me it happens on many files that are compiled with $ make GhcStage2HcOpts="-O1 -g" while the stage1 compiler is active. Tomorrow I can add a concrete invocation. Cheers, Gabor Em seg, 21 de ago de 2017 às 17:49, Simon Peyton Jones < simonpj at microsoft.com> escreveu: > | Oh dear, then I've really misunderstood the intent of this warning. I've > | been noticing these during the GHC build for quite some time now. > > Really? > > After stumbling on #14142, I removed -dno-debug-output from mk/flavours/ > validate.mk and re-validated. Not a single occurrence of > > | > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | > | OccurAnal failed to rediscover join point(s): [go58_akKa] > > How can I reproduce what you are seeing? > > Simon > > | -----Original Message----- > | From: Ben Gamari [mailto:ben at smart-cactus.org] > | Sent: 19 August 2017 16:54 > | To: Simon Peyton Jones ; Gabor Greif > | > | Cc: ghc-devs > | Subject: RE: Stg-lint and bootstrapping (fails?) > | > | Simon Peyton Jones writes: > | > | > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | > | OccurAnal failed to rediscover join point(s): [go58_akKa] > | > > | > That shouldn't happen! If you can make a repro case, please open a > | ticket. > | > > | Oh dear, then I've really misunderstood the intent of this warning. I've > | been noticing these during the GHC build for quite some time now. > | > | Cheers, > | > | - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Tue Aug 22 03:17:29 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 21 Aug 2017 23:17:29 -0400 Subject: Disabling Travis? In-Reply-To: <1503302065.29178.1.camel@joachim-breitner.de> References: <1503245493.4020.2.camel@joachim-breitner.de> <7920340D-2B0B-426E-8960-8A391AA46689@cs.brynmawr.edu> <1503302065.29178.1.camel@joachim-breitner.de> Message-ID: <2E2A20F3-7185-4ABA-8AD8-EDA2A4DE036B@cs.brynmawr.edu> I have not been getting emails from Travis, despite using it for other projects (and thus being registered). So perhaps something is going wrong there. Regardless, it's useful for me, even without the emails. Another nice thing about Travis: I can get a quick check of the history of failures, even in DEBUG mode. Richard > On Aug 21, 2017, at 3:54 AM, Joachim Breitner wrote: > > Hi, > > Am Sonntag, den 20.08.2017, 23:55 -0400 schrieb Richard Eisenberg: >> The big minus to Travis, as I see it, are that only committers can >> use it. (A forked repo just doesn't work because of the way that >> submodules are checked out, IIRC.) This minus doesn't affect me, >> however. > > I think the biggest minus is that Travis can either be configured to > send mails to one specific address (as it was initially, when I > received all the mail and could check whether I want to notify the > author), or to the author of the patch, but not both. Currently it is > sent to notify the author, but people seem to simply ignore the mails. > > (Or maybe even only authors who also registered on travis get them?) > > So if there is demand to keep using Travis, maybe we have to go back to > sending notification mails to one person who oversees this service? > > Joachim > > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ggreif at gmail.com Tue Aug 22 08:56:33 2017 From: ggreif at gmail.com (Gabor Greif) Date: Tue, 22 Aug 2017 10:56:33 +0200 Subject: Stg-lint and bootstrapping (fails?) In-Reply-To: References: <87inhne2j6.fsf@ben-laptop.smart-cactus.org> <87ziava6z9.fsf@ben-laptop.smart-cactus.org> Message-ID: On 8/21/17, Gabor Greif wrote: > Hi Simon, > > for me it happens on many files that are compiled with > > $ make GhcStage2HcOpts="-O1 -g" > > while the stage1 compiler is active. > > Tomorrow I can add a concrete invocation. Here is it: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.6.1.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O1 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/typecheck/TcEvidence.hs -o compiler/stage2/build/TcEvidence.o -dyno compiler/stage2/build/TcEvidence.dyn_o WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_soeO] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_soeN] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_sosq] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_soxX] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_soy2] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_soy9] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_soyw] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_sowZ] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_sovR] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_sovx] WARNING: file compiler/simplCore/SimplCore.hs, line 700 Simplifier bailing out after 4 iterations [721, 479, 80, 4] Size = {terms: 8,035, types: 8,864, coercions: 1,129, joins: 0/96} WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 [] WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 [] WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 [] WARNING: file compiler/simplCore/SimplCore.hs, line 1024 Not shorting out: ebv_uniq And with `-g` I get even more: $ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.6.1.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O1 -g -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/typecheck/TcEvidence.hs -o compiler/stage2/build/TcEvidence.o -dyno compiler/stage2/build/TcEvidence.dyn_o WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_so9S] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_so9R] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_sonu] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_sot1] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_sot6] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_sotd] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_sotA] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_sos3] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_soqV] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [$j_soqB] WARNING: file compiler/simplCore/SimplCore.hs, line 700 Simplifier bailing out after 4 iterations [714, 479, 80, 4] Size = {terms: 8,035, types: 8,864, coercions: 1,129, joins: 0/96} WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 OccurAnal failed to rediscover join point(s): [go58_akL0] ... ETC. Cheers, Gabor > > Cheers, > > Gabor > > Em seg, 21 de ago de 2017 às 17:49, Simon Peyton Jones < > simonpj at microsoft.com> escreveu: > >> | Oh dear, then I've really misunderstood the intent of this warning. >> I've >> | been noticing these during the GHC build for quite some time now. > >> Really? > >> After stumbling on #14142, I removed -dno-debug-output from mk/flavours/ >> validate.mk and re-validated. Not a single occurrence of > >> | > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 >> | > | OccurAnal failed to rediscover join point(s): [go58_akKa] > >> How can I reproduce what you are seeing? > >> Simon > >> | -----Original Message----- >> | From: Ben Gamari [mailto:ben at smart-cactus.org] >> | Sent: 19 August 2017 16:54 >> | To: Simon Peyton Jones ; Gabor Greif >> | >> | Cc: ghc-devs >> | Subject: RE: Stg-lint and bootstrapping (fails?) >> | >> | Simon Peyton Jones writes: >> | >> | > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 >> | > | OccurAnal failed to rediscover join point(s): [go58_akKa] >> | > >> | > That shouldn't happen! If you can make a repro case, please open a >> | ticket. >> | > >> | Oh dear, then I've really misunderstood the intent of this warning. >> I've >> | been noticing these during the GHC build for quite some time now. >> | >> | Cheers, >> | >> | - Ben > > > From simonpj at microsoft.com Tue Aug 22 09:37:45 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 22 Aug 2017 09:37:45 +0000 Subject: Docs Message-ID: Ben et al I’m getting this on Linux when making documentation. I have not modified any of this documentation. Any ideas? Simon reading sources... [ 97%] what_glasgow_exts_does reading sources... [100%] win32-dlls reading sources... [ 97%] what_glasgow_exts_does reading sources... [100%] win32-dlls /5playpen/simonpj/HEAD-1/docs/users_guide/editing-guide.rst:398: ERROR: Error in "ghci-cmd" directive: invalid option block. .. ghci-cmd:: :module; [*]⟨file⟩ :noindex: Load a module /5playpen/simonpj/HEAD-1/docs/users_guide/ghci.rst:496: ERROR: Error in "ghci-cmd" directive: invalid option block. .. ghci-cmd:: :{ :} Begin or end a multi-line GHCi command block. /5playpen/simonpj/HEAD-1/docs/users_guide/ghci.rst:527: ERROR: Error in "warning" directive: invalid option block. .. warning:: Temporary bindings introduced at the prompt only last until the next :ghci-cmd:`:load` or :ghci-cmd:`:reload` command, at which time they will be simply lost. However, they do survive a change of context with :ghci-cmd:`:module`: the temporary bindings just move to the new location. /5playpen/simonpj/HEAD-1/docs/users_guide/ghci.rst:533: ERROR: Error in "hint" directive: invalid option block. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Aug 22 09:45:13 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 22 Aug 2017 09:45:13 +0000 Subject: Stg-lint and bootstrapping (fails?) In-Reply-To: References: <87inhne2j6.fsf@ben-laptop.smart-cactus.org> <87ziava6z9.fsf@ben-laptop.smart-cactus.org> Message-ID: Is this with HEAD? I have an up to date HEAD, and with your command line I don't get those warnings. But I do get the OccAnal warnings, so it's not that the warnings are being suppressed. I'm not sure how to reproduce. Does this happen on anything smaller? Eg. on a testsuite program (you'll need to switch off the -dno-debug-output)? Simon | -----Original Message----- | From: Gabor Greif [mailto:ggreif at gmail.com] | Sent: 22 August 2017 09:57 | To: Simon Peyton Jones ; ghc-devs | Subject: Re: Stg-lint and bootstrapping (fails?) | | On 8/21/17, Gabor Greif wrote: | > Hi Simon, | > | > for me it happens on many files that are compiled with | > | > $ make GhcStage2HcOpts="-O1 -g" | > | > while the stage1 compiler is active. | > | > Tomorrow I can add a concrete invocation. | | Here is it: | | "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall | -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist - | Iincludes/dist-derivedconstants/header | -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 -hide-all-packages | -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm - | icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci - | icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main - | icompiler/nativeGen -icompiler/parser -icompiler/prelude - | icompiler/profiling -icompiler/rename -icompiler/simplCore - | icompiler/simplStg -icompiler/specialise -icompiler/stgSyn - | icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils - | icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build - | icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen - | Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build | -Icompiler/stage2 -optP-DGHCI -optP-include - | optPcompiler/stage2/build/./autogen/cabal_macros.h | -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id | directory-1.3.0.2 -package-id process-1.6.1.0 -package-id | bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id | time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 - | package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0 -package- | id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id | ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id | unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing - | this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS - | DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing | -O1 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir | compiler/stage2/build -hidir compiler/stage2/build -stubdir | compiler/stage2/build -dynamic-too -c compiler/typecheck/TcEvidence.hs -o | compiler/stage2/build/TcEvidence.o -dyno | compiler/stage2/build/TcEvidence.dyn_o | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_soeO] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_soeN] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_sosq] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_soxX] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_soy2] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_soy9] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_soyw] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_sowZ] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_sovR] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_sovx] | WARNING: file compiler/simplCore/SimplCore.hs, line 700 | Simplifier bailing out after 4 iterations [721, 479, 80, 4] | Size = {terms: 8,035, types: 8,864, coercions: 1,129, joins: 0/96} | WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 [] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 [] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 [] | WARNING: file compiler/simplCore/SimplCore.hs, line 1024 | Not shorting out: ebv_uniq | | | And with `-g` I get even more: | | | $ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m - | Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist - | Iincludes/dist-derivedconstants/header | -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 -hide-all-packages | -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm - | icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci - | icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main - | icompiler/nativeGen -icompiler/parser -icompiler/prelude - | icompiler/profiling -icompiler/rename -icompiler/simplCore - | icompiler/simplStg -icompiler/specialise -icompiler/stgSyn - | icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils - | icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build - | icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen - | Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build | -Icompiler/stage2 -optP-DGHCI -optP-include - | optPcompiler/stage2/build/./autogen/cabal_macros.h | -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id | directory-1.3.0.2 -package-id process-1.6.1.0 -package-id | bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id | time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 - | package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0 -package- | id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id | ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id | unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing - | this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS - | DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing | -O1 -g -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir | compiler/stage2/build -hidir compiler/stage2/build -stubdir | compiler/stage2/build -dynamic-too -c compiler/typecheck/TcEvidence.hs -o | compiler/stage2/build/TcEvidence.o -dyno | compiler/stage2/build/TcEvidence.dyn_o | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_so9S] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_so9R] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_sonu] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_sot1] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_sot6] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_sotd] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_sotA] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_sos3] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_soqV] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [$j_soqB] | WARNING: file compiler/simplCore/SimplCore.hs, line 700 | Simplifier bailing out after 4 iterations [714, 479, 80, 4] | Size = {terms: 8,035, types: 8,864, coercions: 1,129, joins: 0/96} | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akL0] ... ETC. | | Cheers, | | Gabor | | | | > | > Cheers, | > | > Gabor | > | > Em seg, 21 de ago de 2017 às 17:49, Simon Peyton Jones < | > simonpj at microsoft.com> escreveu: | > | >> | Oh dear, then I've really misunderstood the intent of this warning. | >> I've | >> | been noticing these during the GHC build for quite some time now. | > | >> Really? | > | >> After stumbling on #14142, I removed -dno-debug-output from | >> mk/flavours/ validate.mk and re-validated. Not a single occurrence | >> of | > | >> | > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | >> | > | OccurAnal failed to rediscover join point(s): [go58_akKa] | > | >> How can I reproduce what you are seeing? | > | >> Simon | > | >> | -----Original Message----- | >> | From: Ben Gamari [mailto:ben at smart-cactus.org] | >> | Sent: 19 August 2017 16:54 | >> | To: Simon Peyton Jones ; Gabor Greif | >> | | >> | Cc: ghc-devs | >> | Subject: RE: Stg-lint and bootstrapping (fails?) | >> | | >> | Simon Peyton Jones writes: | >> | | >> | > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | >> | > | OccurAnal failed to rediscover join point(s): [go58_akKa] | >> | > | >> | > That shouldn't happen! If you can make a repro case, please | >> | open a ticket. | >> | > | >> | Oh dear, then I've really misunderstood the intent of this warning. | >> I've | >> | been noticing these during the GHC build for quite some time now. | >> | | >> | Cheers, | >> | | >> | - Ben | > | > | > From ben at smart-cactus.org Tue Aug 22 13:50:45 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 22 Aug 2017 09:50:45 -0400 Subject: Phab: conditional approval In-Reply-To: <95D2EA45-B7A1-497E-B174-2D8037054C36@cs.brynmawr.edu> References: <95D2EA45-B7A1-497E-B174-2D8037054C36@cs.brynmawr.edu> Message-ID: <87o9r7aeyy.fsf@ben-laptop.smart-cactus.org> Richard Eisenberg writes: > Hi devs, > > When reviewing a diff on Phab, I can "accept" or "request changes". > Sometimes, though, I want to do both: I suggest very minor (e.g., > typo) changes, but then when these changes are made, I accept. I'm > leery of making the suggestions and saying "accept", because then > someone working quickly may merge without noticing the typos. Does > Phab have such an option? > I have also wanted such an option in the past. In general I think the accept/request changes responses are a bit coarse-grained: I sometimes need to hold off on accepting patches merely to ensure that others have a chance to review before merge. We could open a ticket with Phacility asking whether a finer mechanism is something they would entertain. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Tue Aug 22 13:54:59 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 22 Aug 2017 09:54:59 -0400 Subject: Docs In-Reply-To: References: Message-ID: <87mv6raerw.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Ben et al > I’m getting this on Linux when making documentation. I have not > modified any of this documentation. Any ideas? Strangely I'm not able to reproduce any of these. Do these cause the build to fail? What does sphinx-build --version say? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Tue Aug 22 14:07:20 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 22 Aug 2017 14:07:20 +0000 Subject: Docs In-Reply-To: <87mv6raerw.fsf@ben-laptop.smart-cactus.org> References: <87mv6raerw.fsf@ben-laptop.smart-cactus.org> Message-ID: sphinx-build --version Sphinx v1.1.3 | -----Original Message----- | From: Ben Gamari [mailto:ben at smart-cactus.org] | Sent: 22 August 2017 14:55 | To: Simon Peyton Jones ; ghc-devs | Subject: Re: Docs | | Simon Peyton Jones via ghc-devs writes: | | > Ben et al | > I’m getting this on Linux when making documentation. I have not | > modified any of this documentation. Any ideas? | | Strangely I'm not able to reproduce any of these. Do these cause the build | to fail? | | What does sphinx-build --version say? | | Cheers, | | - Ben From sh.najd at gmail.com Wed Aug 23 12:26:08 2017 From: sh.najd at gmail.com (Shayan Najd) Date: Wed, 23 Aug 2017 14:26:08 +0200 Subject: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs Message-ID: In this thread, I am going to raise a topic for discussion. Please share your opinions and related experiences. Evaluation of type families within HsSyn ASTs, such as `PostTc`, with a fixed phase index, such as `GhcPs`, gives us distinct ASTs at the *compile-time*. However, when programming with these ASTs, we use patterns, such as `HsMultiIf :: PostTc p Type -> [LGRHS p (LHsExpr p)] -> HsExpr p` that are shared among phases. We can (1) introduce a layer of abstraction providing a set of type and pattern synonyms specific to each phase, such as `PsMultiIf :: [LPsGRHS LPsExpr] -> PsExpr`; and (2) updating code working on ASTs of specific phase to use the interface specific to the phase, such as by changing prefixes from `Hs` to `Ps` and by removing unused variables and placeholders; and (3) leaving untouched code working uniformly on ASTs of different phases (i.e., the generic functions in Trees that Grow terminology), such as the existing functions whose types are polymorphic on phase index. Some comments: - It can be done gradually and smoothly: we add three separate files in HsSyn (per each phase) containing the phase-specific interfaces, and gradually import them and do the changes per module. - Using the interfaces is optional: code using the current method (e.g., using `HsMultiIf`) should work just fine. - It introduces a layer of indirection and three more files to maintain. - It makes code working on HsSyn ASTs, such as the renamer, appear cleaner as placeholders and similar machinery are abstracted away by the interfaces (e.g., no need to import bits and pieces of `HsExtension`) - In theory, there should be zero impact on GHC's runtime performance. I am myself undecided about its benefit-cost ratio, but willing to at least implement the phase-specific interfaces. For me, abstracting away all the `PostRn` stuff, `Out` prefixed constructors, and dummy placeholders from the front-end code is the most valuable. Yours, Shayan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Thu Aug 24 10:56:47 2017 From: ggreif at gmail.com (Gabor Greif) Date: Thu, 24 Aug 2017 12:56:47 +0200 Subject: Stg-lint and bootstrapping (fails?) In-Reply-To: References: <87inhne2j6.fsf@ben-laptop.smart-cactus.org> <87ziava6z9.fsf@ben-laptop.smart-cactus.org> Message-ID: Indeed, it does not happen on fresh HEAD, I'll have to dig deeper. Maybe it is related to my changes, but I only changed Stg-related stuff. Join-points are a Core thing, right? Anyway, I'll keep you informed if I figure it out. Cheers, Gabor On 8/22/17, Simon Peyton Jones wrote: > Is this with HEAD? I have an up to date HEAD, and with your command line I > don't get those warnings. But I do get the OccAnal warnings, so it's not > that the warnings are being suppressed. > > I'm not sure how to reproduce. > > Does this happen on anything smaller? Eg. on a testsuite program (you'll > need to switch off the -dno-debug-output)? > > Simon > > | -----Original Message----- > | From: Gabor Greif [mailto:ggreif at gmail.com] > | Sent: 22 August 2017 09:57 > | To: Simon Peyton Jones ; ghc-devs | devs at haskell.org> > | Subject: Re: Stg-lint and bootstrapping (fails?) > | > | On 8/21/17, Gabor Greif wrote: > | > Hi Simon, > | > > | > for me it happens on many files that are compiled with > | > > | > $ make GhcStage2HcOpts="-O1 -g" > | > > | > while the stage1 compiler is active. > | > > | > Tomorrow I can add a concrete invocation. > | > | Here is it: > | > | "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m > -Wall > | -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist - > | Iincludes/dist-derivedconstants/header > | -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 > -hide-all-packages > | -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm - > | icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci > - > | icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main - > | icompiler/nativeGen -icompiler/parser -icompiler/prelude - > | icompiler/profiling -icompiler/rename -icompiler/simplCore - > | icompiler/simplStg -icompiler/specialise -icompiler/stgSyn - > | icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils > - > | icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build - > | icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen - > | Icompiler/. -Icompiler/parser -Icompiler/utils > -Icompiler/../rts/dist/build > | -Icompiler/stage2 -optP-DGHCI -optP-include - > | optPcompiler/stage2/build/./autogen/cabal_macros.h > | -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id > | directory-1.3.0.2 -package-id process-1.6.1.0 -package-id > | bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id > | time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 - > | package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0 > -package- > | id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id > | ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 > -package-id > | unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing > - > | this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS - > | DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing > | -O1 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir > | compiler/stage2/build -hidir compiler/stage2/build -stubdir > | compiler/stage2/build -dynamic-too -c compiler/typecheck/TcEvidence.hs > -o > | compiler/stage2/build/TcEvidence.o -dyno > | compiler/stage2/build/TcEvidence.dyn_o > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_soeO] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_soeN] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_sosq] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_soxX] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_soy2] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_soy9] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_soyw] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_sowZ] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_sovR] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_sovx] > | WARNING: file compiler/simplCore/SimplCore.hs, line 700 > | Simplifier bailing out after 4 iterations [721, 479, 80, 4] > | Size = {terms: 8,035, types: 8,864, coercions: 1,129, joins: 0/96} > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 [] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 [] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 [] > | WARNING: file compiler/simplCore/SimplCore.hs, line 1024 > | Not shorting out: ebv_uniq > | > | > | And with `-g` I get even more: > | > | > | $ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m > - > | Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist - > | Iincludes/dist-derivedconstants/header > | -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 > -hide-all-packages > | -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm - > | icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci > - > | icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main - > | icompiler/nativeGen -icompiler/parser -icompiler/prelude - > | icompiler/profiling -icompiler/rename -icompiler/simplCore - > | icompiler/simplStg -icompiler/specialise -icompiler/stgSyn - > | icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils > - > | icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build - > | icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen - > | Icompiler/. -Icompiler/parser -Icompiler/utils > -Icompiler/../rts/dist/build > | -Icompiler/stage2 -optP-DGHCI -optP-include - > | optPcompiler/stage2/build/./autogen/cabal_macros.h > | -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id > | directory-1.3.0.2 -package-id process-1.6.1.0 -package-id > | bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id > | time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 - > | package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0 > -package- > | id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id > | ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 > -package-id > | unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing > - > | this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS - > | DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing > | -O1 -g -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir > | compiler/stage2/build -hidir compiler/stage2/build -stubdir > | compiler/stage2/build -dynamic-too -c compiler/typecheck/TcEvidence.hs > -o > | compiler/stage2/build/TcEvidence.o -dyno > | compiler/stage2/build/TcEvidence.dyn_o > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_so9S] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_so9R] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_sonu] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_sot1] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_sot6] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_sotd] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_sotA] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_sos3] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_soqV] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [$j_soqB] > | WARNING: file compiler/simplCore/SimplCore.hs, line 700 > | Simplifier bailing out after 4 iterations [714, 479, 80, 4] > | Size = {terms: 8,035, types: 8,864, coercions: 1,129, joins: 0/96} > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | OccurAnal failed to rediscover join point(s): [go58_akL0] ... ETC. > | > | Cheers, > | > | Gabor > | > | > | > | > > | > Cheers, > | > > | > Gabor > | > > | > Em seg, 21 de ago de 2017 às 17:49, Simon Peyton Jones < > | > simonpj at microsoft.com> escreveu: > | > > | >> | Oh dear, then I've really misunderstood the intent of this > warning. > | >> I've > | >> | been noticing these during the GHC build for quite some time now. > | > > | >> Really? > | > > | >> After stumbling on #14142, I removed -dno-debug-output from > | >> mk/flavours/ validate.mk and re-validated. Not a single occurrence > | >> of > | > > | >> | > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | >> | > | OccurAnal failed to rediscover join point(s): [go58_akKa] > | > > | >> How can I reproduce what you are seeing? > | > > | >> Simon > | > > | >> | -----Original Message----- > | >> | From: Ben Gamari [mailto:ben at smart-cactus.org] > | >> | Sent: 19 August 2017 16:54 > | >> | To: Simon Peyton Jones ; Gabor Greif > | >> | > | >> | Cc: ghc-devs > | >> | Subject: RE: Stg-lint and bootstrapping (fails?) > | >> | > | >> | Simon Peyton Jones writes: > | >> | > | >> | > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 > | >> | > | OccurAnal failed to rediscover join point(s): [go58_akKa] > | >> | > > | >> | > That shouldn't happen! If you can make a repro case, please > | >> | open a ticket. > | >> | > > | >> | Oh dear, then I've really misunderstood the intent of this > warning. > | >> I've > | >> | been noticing these during the GHC build for quite some time now. > | >> | > | >> | Cheers, > | >> | > | >> | - Ben > | > > | > > | > > From ben at well-typed.com Thu Aug 24 12:52:39 2017 From: ben at well-typed.com (Ben Gamari) Date: Thu, 24 Aug 2017 08:52:39 -0400 Subject: Alex install failure In-Reply-To: References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> Message-ID: <87lgm9yvoo.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones writes: > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. > So what? Hi Simon, Sorry for the rather belated reply; I was knocked off my feet for a few days by a rather nasty tetanus vaccination. Anyways, I have a patch which I suspect will help. It seems that some NFS implementations incur a rather long delay (order of seconds) between the time a file handle is closed and an open flock lock on the handle being released. I suspect this delay won't exist in cases where we explicitly funlock before closing the file handle. I have implemented this in wip/ghc-pkg-locking. Do you think you could give this branch a try? If it still fails then we'll have to try to debug things in-situ. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Thu Aug 24 13:35:41 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 24 Aug 2017 13:35:41 +0000 Subject: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs In-Reply-To: References: Message-ID: I’m keen NOT to introduce these layers of indirection. I think they make the code harder to understand. Can you give an example function or two, and what it would look like under the different approaches. (1)-(3) appears to be three different approaches, but I don’t think that’s what you intend. I think there are only two: add the indirection layer or not? S From: Shayan Najd [mailto:sh.najd at gmail.com] Sent: 23 August 2017 13:26 To: ghc-devs at haskell.org Cc: Simon Peyton Jones ; Alan & Kim Zimmerman Subject: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs In this thread, I am going to raise a topic for discussion. Please share your opinions and related experiences. Evaluation of type families within HsSyn ASTs, such as `PostTc`, with a fixed phase index, such as `GhcPs`, gives us distinct ASTs at the *compile-time*. However, when programming with these ASTs, we use patterns, such as `HsMultiIf :: PostTc p Type -> [LGRHS p (LHsExpr p)] -> HsExpr p` that are shared among phases. We can (1) introduce a layer of abstraction providing a set of type and pattern synonyms specific to each phase, such as `PsMultiIf :: [LPsGRHS LPsExpr] -> PsExpr`; and (2) updating code working on ASTs of specific phase to use the interface specific to the phase, such as by changing prefixes from `Hs` to `Ps` and by removing unused variables and placeholders; and (3) leaving untouched code working uniformly on ASTs of different phases (i.e., the generic functions in Trees that Grow terminology), such as the existing functions whose types are polymorphic on phase index. Some comments: - It can be done gradually and smoothly: we add three separate files in HsSyn (per each phase) containing the phase-specific interfaces, and gradually import them and do the changes per module. - Using the interfaces is optional: code using the current method (e.g., using `HsMultiIf`) should work just fine. - It introduces a layer of indirection and three more files to maintain. - It makes code working on HsSyn ASTs, such as the renamer, appear cleaner as placeholders and similar machinery are abstracted away by the interfaces (e.g., no need to import bits and pieces of `HsExtension`) - In theory, there should be zero impact on GHC's runtime performance. I am myself undecided about its benefit-cost ratio, but willing to at least implement the phase-specific interfaces. For me, abstracting away all the `PostRn` stuff, `Out` prefixed constructors, and dummy placeholders from the front-end code is the most valuable. Yours, Shayan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh.najd at gmail.com Thu Aug 24 14:38:51 2017 From: sh.najd at gmail.com (Shayan Najd) Date: Thu, 24 Aug 2017 16:38:51 +0200 Subject: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs In-Reply-To: References: Message-ID: > > (1)-(3) appears to be three different approaches, but I don’t think that’s > what you intend. I think there are only two: add the indirection layer or > not? (1)-(3) are just steps when we do choose to add the indirection layer: add the layer, and do the changes when desired. If we choose to not to add the indirection layer, nothing needs to be changed and the internals of the encoding (`PostTc`, place holders, etc) remain visible in the code. Can you give an example function or two, and what it would look like under > the different approaches. For example, the function clause > rnExpr (HsMultiIf _ty alts) > = do { (alts', fvs) <- mapFvRn (rnGRHS IfAlt rnLExpr) alts > ; return (HsMultiIf placeHolderType alts', fvs) } becomes > rnExpr (PsMultiIf alts) > = do { (alts', fvs) <- mapFvRn (rnGRHS IfAlt rnLExpr) alts > ; return (RnMultiIf alts', fvs) } I hope it clarifies what I mean a bit. There is always a choice between how distinct we want the phases to be. The more distinct they are, the higher static guarantees. The code also gets more clear in a way, e.g. `RnMultiIf` is talking about a renamed expression, `PsMultiIf` about a parsed expression, while `HsMultiIf` is talking about an expression of any phase. At the same, distinctness means more work for the programmer. Also, such distinction sometimes implies a pedagogic burdon, as readers should now learn about more than one AST. However, this burden is very low here thanks to the prefixing convention: `PsMultiIf` and `RnMultiIf` are easily understood to represent the same thing in different phases. Finally, such distinctions often lead to code duplication. But in our case, Trees that Grow machinery saves us from such duplication, e.g., we have the same base ASTs and we can write generic programmers over the bases ASTs anytime we want (point/step (3) above). Thanks, Shayan On Thu, Aug 24, 2017 at 3:35 PM, Simon Peyton Jones wrote: > I’m keen NOT to introduce these layers of indirection. I think they make > the code harder to understand. > > > Can you give an example function or two, and what it would look like under > the different approaches. > > > > (1)-(3) appears to be three different approaches, but I don’t think that’s > what you intend. I think there are only two: add the indirection layer or > not? > > > > S > > > > *From:* Shayan Najd [mailto:sh.najd at gmail.com] > *Sent:* 23 August 2017 13:26 > *To:* ghc-devs at haskell.org > *Cc:* Simon Peyton Jones ; Alan & Kim Zimmerman < > alan.zimm at gmail.com> > *Subject:* Discussion: Static Safety via Distinct Interfaces for HsSyn > ASTs > > > > In this thread, I am going to raise a topic for discussion. Please share > your opinions and related experiences. > > > > Evaluation of type families within HsSyn ASTs, such as `PostTc`, with a > fixed phase index, such as `GhcPs`, gives us distinct ASTs at the > *compile-time*. > > However, when programming with these ASTs, we use patterns, such as `HsMultiIf > :: PostTc p Type -> [LGRHS p (LHsExpr p)] -> HsExpr p` that are shared > among phases. > > We can > > (1) introduce a layer of abstraction providing a set of type and pattern > synonyms specific to each phase, such as `PsMultiIf :: [LPsGRHS LPsExpr] > -> PsExpr`; and > > (2) updating code working on ASTs of specific phase to use the interface > specific to the phase, such as by changing prefixes from `Hs` to `Ps` and > by removing unused variables and placeholders; and > > (3) leaving untouched code working uniformly on ASTs of different phases > (i.e., the generic functions in Trees that Grow terminology), such as the > existing functions whose types are polymorphic on phase index. > > > > Some comments: > > > > - It can be done gradually and smoothly: we add three separate files in > HsSyn (per each phase) containing the phase-specific interfaces, and > gradually import them and do the changes per module. > > - Using the interfaces is optional: code using the current method (e.g., > using `HsMultiIf`) should work just fine. > > - It introduces a layer of indirection and three more files to maintain. > > - It makes code working on HsSyn ASTs, such as the renamer, appear cleaner > as placeholders and similar machinery are abstracted away by the interfaces > (e.g., no need to import bits and pieces of `HsExtension`) > > - In theory, there should be zero impact on GHC's runtime performance. > > > > I am myself undecided about its benefit-cost ratio, but willing to at > least implement the phase-specific interfaces. > > For me, abstracting away all the `PostRn` stuff, `Out` prefixed > constructors, and dummy placeholders from the front-end code is the most > valuable. > > > > Yours, > > Shayan > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Aug 25 09:28:59 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 25 Aug 2017 09:28:59 +0000 Subject: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs In-Reply-To: References: Message-ID: Hmm I see. I still prefer the concrete form (no intermediate layer). Many constructors use record fields, so you can just omit the ones that aren’t valid. Simon From: Shayan Najd [mailto:sh.najd at gmail.com] Sent: 24 August 2017 15:39 To: Simon Peyton Jones Cc: Alan & Kim Zimmerman ; ghc-devs at haskell.org Subject: Re: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs (1)-(3) appears to be three different approaches, but I don’t think that’s what you intend. I think there are only two: add the indirection layer or not? (1)-(3) are just steps when we do choose to add the indirection layer: add the layer, and do the changes when desired. If we choose to not to add the indirection layer, nothing needs to be changed and the internals of the encoding (`PostTc`, place holders, etc) remain visible in the code. Can you give an example function or two, and what it would look like under the different approaches. For example, the function clause > rnExpr (HsMultiIf _ty alts) > = do { (alts', fvs) <- mapFvRn (rnGRHS IfAlt rnLExpr) alts > ; return (HsMultiIf placeHolderType alts', fvs) } becomes > rnExpr (PsMultiIf alts) > = do { (alts', fvs) <- mapFvRn (rnGRHS IfAlt rnLExpr) alts > ; return (RnMultiIf alts', fvs) } I hope it clarifies what I mean a bit. There is always a choice between how distinct we want the phases to be. The more distinct they are, the higher static guarantees. The code also gets more clear in a way, e.g. `RnMultiIf` is talking about a renamed expression, `PsMultiIf` about a parsed expression, while `HsMultiIf` is talking about an expression of any phase. At the same, distinctness means more work for the programmer. Also, such distinction sometimes implies a pedagogic burdon, as readers should now learn about more than one AST. However, this burden is very low here thanks to the prefixing convention: `PsMultiIf` and `RnMultiIf` are easily understood to represent the same thing in different phases. Finally, such distinctions often lead to code duplication. But in our case, Trees that Grow machinery saves us from such duplication, e.g., we have the same base ASTs and we can write generic programmers over the bases ASTs anytime we want (point/step (3) above). Thanks, Shayan On Thu, Aug 24, 2017 at 3:35 PM, Simon Peyton Jones > wrote: I’m keen NOT to introduce these layers of indirection. I think they make the code harder to understand. Can you give an example function or two, and what it would look like under the different approaches. (1)-(3) appears to be three different approaches, but I don’t think that’s what you intend. I think there are only two: add the indirection layer or not? S From: Shayan Najd [mailto:sh.najd at gmail.com] Sent: 23 August 2017 13:26 To: ghc-devs at haskell.org Cc: Simon Peyton Jones >; Alan & Kim Zimmerman > Subject: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs In this thread, I am going to raise a topic for discussion. Please share your opinions and related experiences. Evaluation of type families within HsSyn ASTs, such as `PostTc`, with a fixed phase index, such as `GhcPs`, gives us distinct ASTs at the *compile-time*. However, when programming with these ASTs, we use patterns, such as `HsMultiIf :: PostTc p Type -> [LGRHS p (LHsExpr p)] -> HsExpr p` that are shared among phases. We can (1) introduce a layer of abstraction providing a set of type and pattern synonyms specific to each phase, such as `PsMultiIf :: [LPsGRHS LPsExpr] -> PsExpr`; and (2) updating code working on ASTs of specific phase to use the interface specific to the phase, such as by changing prefixes from `Hs` to `Ps` and by removing unused variables and placeholders; and (3) leaving untouched code working uniformly on ASTs of different phases (i.e., the generic functions in Trees that Grow terminology), such as the existing functions whose types are polymorphic on phase index. Some comments: - It can be done gradually and smoothly: we add three separate files in HsSyn (per each phase) containing the phase-specific interfaces, and gradually import them and do the changes per module. - Using the interfaces is optional: code using the current method (e.g., using `HsMultiIf`) should work just fine. - It introduces a layer of indirection and three more files to maintain. - It makes code working on HsSyn ASTs, such as the renamer, appear cleaner as placeholders and similar machinery are abstracted away by the interfaces (e.g., no need to import bits and pieces of `HsExtension`) - In theory, there should be zero impact on GHC's runtime performance. I am myself undecided about its benefit-cost ratio, but willing to at least implement the phase-specific interfaces. For me, abstracting away all the `PostRn` stuff, `Out` prefixed constructors, and dummy placeholders from the front-end code is the most valuable. Yours, Shayan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Aug 25 14:40:45 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 25 Aug 2017 14:40:45 +0000 Subject: Alex install failure In-Reply-To: <87lgm9yvoo.fsf@ben-laptop.smart-cactus.org> References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> <87lgm9yvoo.fsf@ben-laptop.smart-cactus.org> Message-ID: | I have implemented this in wip/ghc-pkg-locking. Do you think you could give | this branch a try? If it still fails then we'll have to try to debug things | in-situ. Alas, no go. * I'm on wip/ghc-pkg-locking * I checked that the lock file was removed then I tried this: simonpj at cam-05-unx:~/code/HEAD-2$ cabal install lens --with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2 Resolving dependencies... Configuring base-orphans-0.6... Configuring cabal-doctest-1.0.2... Configuring call-stack-0.1.0... Configuring fail-4.9.0.0... Configuring hashable-1.2.6.1... Configuring parallel-3.2.1.1... Configuring prelude-extras-0.4.0.3... Configuring primitive-0.6.2.0... Configuring reflection-2.1.2... Configuring semigroups-0.18.3... Configuring stm-2.4.4.1... Configuring th-abstraction-0.2.5.0... Configuring transformers-compat-0.5.1.4... Configuring void-0.7.2... Building base-orphans-0.6... Building cabal-doctest-1.0.2... Building fail-4.9.0.0... Building call-stack-0.1.0... Building parallel-3.2.1.1... Building hashable-1.2.6.1... Building primitive-0.6.2.0... Building prelude-extras-0.4.0.3... Building reflection-2.1.2... Building semigroups-0.18.3... Building stm-2.4.4.1... Building void-0.7.2... Building th-abstraction-0.2.5.0... Building transformers-compat-0.5.1.4... Installed fail-4.9.0.0 Failed to install base-orphans-0.6 Build log ( /home/simonpj/.cabal/logs/base-orphans-0.6.log ): cabal: Entering directory '/tmp/cabal-tmp-28239/base-orphans-0.6' Configuring base-orphans-0.6... Building base-orphans-0.6... Preprocessing library base-orphans-0.6... [1 of 2] Compiling Data.Orphans ( src/Data/Orphans.hs, dist/build/Data/Orphans.o ) [2 of 2] Compiling Data.Orphans.Prelude ( src/Data/Orphans/Prelude.hs, dist/build/Data/Orphans/Prelude.o ) Creating package registration file: /tmp/pkgConf-base-orphans-010599613932089018456.6 Installing library in /home/simonpj/.cabal/lib/x86_64-linux-ghc-8.3.20170825/base-orphans-0.6-9iPDLrUqQ5yHb9fb9OUZ9L Registering base-orphans-0.6... cabal: '/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-pkg' exited with an error: ghc-pkg: Couldn't open database /home/simonpj/.ghc/x86_64-linux-8.3.20170825/package.conf.d for modification: {handle: /home/simonpj/.ghc/x86_64-linux-8.3.20170825/package.conf.d/package.cache.lock}: hLock: invalid argument (Bad file descriptor) cabal: Leaving directory '/tmp/cabal-tmp-28239/base-orphans-0.6' Failed to install void-0.7.2 Build log ( /home/simonpj/.cabal/logs/void-0.7.2.log ): cabal: Entering directory '/tmp/cabal-tmp-28252/void-0.7.2' Configuring void-0.7.2... Building void-0.7.2... Preprocessing library void-0.7.2... [1 of 1] Compiling Data.Void.Unsafe ( src/Data/Void/Unsafe.hs, dist/build/Data/Void/Unsafe.o ) Creating package registration file: /tmp/pkgConf-void-0.76281750111656478042.2 Installing library in /home/simonpj/.cabal/lib/x86_64-linux-ghc-8.3.20170825/void-0.7.2-KNNEd7XG9bDRysTndgnf2 Registering void-0.7.2... cabal: '/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-pkg' exited with an error: ghc-pkg: Couldn't open database /home/simonpj/.ghc/x86_64-linux-8.3.20170825/package.conf.d for modification: {handle: /home/simonpj/.ghc/x86_64-linux-8.3.20170825/package.conf.d/package.cache.lock}: hLock: invalid argument (Bad file descriptor) cabal: Leaving directory '/tmp/cabal-tmp-28252/void-0.7.2' Failed to install semigroups-0.18.3 Build log ( /home/simonpj/.cabal/logs/semigroups-0.18.3.log ): cabal: Entering directory '/tmp/cabal-tmp-28248/semigroups-0.18.3' Configuring semigroups-0.18.3... Building semigroups-0.18.3... Preprocessing library semigroups-0.18.3... [1 of 1] Compiling Data.Semigroup.Generic ( src/Data/Semigroup/Generic.hs, dist/build/Data/Semigroup/Generic.o ) Creating package registration file: /tmp/pkgConf-semigroups-0.188594844211914544919.3 Installing library in /home/simonpj/.cabal/lib/x86_64-linux-ghc-8.3.20170825/semigroups-0.18.3-9GRyDnRvoqO5HfdYR3Qz4o Registering semigroups-0.18.3... cabal: '/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-pkg' exited with an error: ghc-pkg: Couldn't open database /home/simonpj/.ghc/x86_64-linux-8.3.20170825/package.conf.d for modification: {handle: /home/simonpj/.ghc/x86_64-linux-8.3.20170825/package.conf.d/package.cache.lock}: hLock: invalid argument (Bad file descriptor) cabal: Leaving directory '/tmp/cabal-tmp-28248/semigroups-0.18.3' C-c C-c simonpj at cam-05-unx:~/code/HEAD-2$ | -----Original Message----- | From: Ben Gamari [mailto:ben at well-typed.com] | Sent: 24 August 2017 13:53 | To: Simon Peyton Jones | Cc: ghc-devs | Subject: RE: Alex install failure | | Simon Peyton Jones writes: | | > | Hmm. Here's a shot in the dark: is home home directory mounted via | > | NFS by any chance? | > | > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. | > So what? | | Hi Simon, | | Sorry for the rather belated reply; I was knocked off my feet for a few days | by a rather nasty tetanus vaccination. | | Anyways, I have a patch which I suspect will help. It seems that some NFS | implementations incur a rather long delay (order of seconds) between the | time a file handle is closed and an open flock lock on the handle being | released. I suspect this delay won't exist in cases where we explicitly | funlock before closing the file handle. | | I have implemented this in wip/ghc-pkg-locking. Do you think you could give | this branch a try? If it still fails then we'll have to try to debug things | in-situ. | | Cheers, | | - Ben From ben at well-typed.com Fri Aug 25 16:45:37 2017 From: ben at well-typed.com (Ben Gamari) Date: Fri, 25 Aug 2017 12:45:37 -0400 Subject: Alex install failure In-Reply-To: References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> <87lgm9yvoo.fsf@ben-laptop.smart-cactus.org> Message-ID: <878ti7zjda.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > | I have implemented this in wip/ghc-pkg-locking. Do you think you could give > | this branch a try? If it still fails then we'll have to try to debug things > | in-situ. > > Alas, no go. > Hmm, alright then. What do the following say, * ps -Af | grep lockd * ps -Af | grep portmap * ps -Af | grep rpcbind * mount | grep nfs Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From harendra.kumar at gmail.com Fri Aug 25 19:06:12 2017 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sat, 26 Aug 2017 00:36:12 +0530 Subject: Where to raise an issue for the stm library Message-ID: Can someone tell me where to raise an issue for the stm library? The hackage link sends me here http://git.haskell.org/packages/stm.git. But this page provides no clue on raising issues. I wondered if GHC trac itself is used for this library. I saw some other libraries in the drop down list but not this one in the GHC trac ticket creation page. It is frustrating that figuring out how to raise an issue is not easy for such an important library. -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From fryguybob at gmail.com Fri Aug 25 19:13:43 2017 From: fryguybob at gmail.com (Ryan Yates) Date: Fri, 25 Aug 2017 15:13:43 -0400 Subject: Where to raise an issue for the stm library In-Reply-To: References: Message-ID: Hi Harendra, I think STM issues are fine to report to GHC's trac (please someone else chime in if this isn't the case): https://ghc.haskell.org/trac/ghc/wiki/ReportABug If that isn't the appropriate place it can get sorted out from there. Ryan On Fri, Aug 25, 2017 at 3:06 PM, Harendra Kumar wrote: > Can someone tell me where to raise an issue for the stm library? The > hackage link sends me here http://git.haskell.org/packages/stm.git. But > this page provides no clue on raising issues. I wondered if GHC trac itself > is used for this library. I saw some other libraries in the drop down list > but not this one in the GHC trac ticket creation page. It is frustrating > that figuring out how to raise an issue is not easy for such an important > library. > > -harendra > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Fri Aug 25 19:15:13 2017 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sat, 26 Aug 2017 00:45:13 +0530 Subject: Where to raise an issue for the stm library In-Reply-To: References: Message-ID: Ok. So I got the bug tracker link from the hackage page which I missed earlier. It will be great if the source repo page as well has a link to the bug tracker. I have never used the bug tracker link on hackage before because I usually go to the package source page and it usually has the issue tracker as well (e.g. for github repos). Also, it may be good to have it as libraries/stm instead of libraries/other in the ghc trac ticket page. -harendra On 26 August 2017 at 00:36, Harendra Kumar wrote: > Can someone tell me where to raise an issue for the stm library? The > hackage link sends me here http://git.haskell.org/packages/stm.git. But > this page provides no clue on raising issues. I wondered if GHC trac itself > is used for this library. I saw some other libraries in the drop down list > but not this one in the GHC trac ticket creation page. It is frustrating > that figuring out how to raise an issue is not easy for such an important > library. > > -harendra > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Fri Aug 25 19:16:55 2017 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sat, 26 Aug 2017 00:46:55 +0530 Subject: Where to raise an issue for the stm library In-Reply-To: References: Message-ID: BTW, this is the bug tracker link I got from the hackage https://ghc.haskell.org/trac/ghc/newticket?component=libraries%20%28other%29&keywords=stm . On 26 August 2017 at 00:45, Harendra Kumar wrote: > Ok. So I got the bug tracker link from the hackage page which I missed > earlier. It will be great if the source repo page as well has a link to the > bug tracker. I have never used the bug tracker link on hackage before > because I usually go to the package source page and it usually has the > issue tracker as well (e.g. for github repos). Also, it may be good to have > it as libraries/stm instead of libraries/other in the ghc trac ticket page. > > -harendra > > On 26 August 2017 at 00:36, Harendra Kumar > wrote: > >> Can someone tell me where to raise an issue for the stm library? The >> hackage link sends me here http://git.haskell.org/packages/stm.git. But >> this page provides no clue on raising issues. I wondered if GHC trac itself >> is used for this library. I saw some other libraries in the drop down list >> but not this one in the GHC trac ticket creation page. It is frustrating >> that figuring out how to raise an issue is not easy for such an important >> library. >> >> -harendra >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sat Aug 26 03:45:14 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 25 Aug 2017 23:45:14 -0400 Subject: Where to raise an issue for the stm library In-Reply-To: References: Message-ID: <874lsvyotx.fsf@ben-laptop.smart-cactus.org> Harendra Kumar writes: > Ok. So I got the bug tracker link from the hackage page which I missed > earlier. It will be great if the source repo page as well has a link to the > bug tracker. I have never used the bug tracker link on hackage before > because I usually go to the package source page and it usually has the > issue tracker as well (e.g. for github repos). Also, it may be good to have > it as libraries/stm instead of libraries/other in the ghc trac ticket page. > I've created a libraries/stm component; I'll update the stm library's cabal file accordingly. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From harendra.kumar at gmail.com Sat Aug 26 04:12:53 2017 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sat, 26 Aug 2017 09:42:53 +0530 Subject: Where to raise an issue for the stm library In-Reply-To: <874lsvyotx.fsf@ben-laptop.smart-cactus.org> References: <874lsvyotx.fsf@ben-laptop.smart-cactus.org> Message-ID: Thanks Ben! You rock! On 26 August 2017 at 09:15, Ben Gamari wrote: > Harendra Kumar writes: > > > Ok. So I got the bug tracker link from the hackage page which I missed > > earlier. It will be great if the source repo page as well has a link to > the > > bug tracker. I have never used the bug tracker link on hackage before > > because I usually go to the package source page and it usually has the > > issue tracker as well (e.g. for github repos). Also, it may be good to > have > > it as libraries/stm instead of libraries/other in the ghc trac ticket > page. > > > I've created a libraries/stm component; I'll update the stm library's > cabal file accordingly. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Aug 27 02:56:30 2017 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 27 Aug 2017 02:56:30 +0000 Subject: New primitive types? In-Reply-To: <87k220rm4v.fsf@mid.deneb.enyo.de> References: <87k220rm4v.fsf@mid.deneb.enyo.de> Message-ID: Which architectures are which? I assume you mean the dec alpha allowed atomic operations on bytes... but your phrasing is a teeny bit unclear On Sat, Aug 19, 2017 at 4:34 AM Florian Weimer wrote: > * Michal Terepeta: > > > On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald < > carter.schonwald at gmail.com> > > wrote: > >> One issue with packed fields is that on many architectures you can't > > quite do subword reads or > >> writes. So it might not always be a win. > > > > Could you give any examples? > > Historic DEC Alpha, now long obsolete. > > It is very hard to create compliant and performant implementations of > Java 5, C 11 or C++ 11 on such architectures. All these languages > (and their subsequent revisions) require that naturally aligned > objects can be accessed independently. For example, you can't use a > simple read-modify-write cycle to implement a single-byte store using > word operations. > > That's why such architectures really do not have a future (or even a > present), except maybe in niche markets such as GPGPU (but even there, > things are heading towards the de-facto standard memory model). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at well-typed.com Sun Aug 27 03:52:12 2017 From: david at well-typed.com (David Feuer) Date: Sat, 26 Aug 2017 23:52:12 -0400 Subject: Tying knots with strict constructors Message-ID: <1784906.ANPOCvADxx@squirrel> Once in a while, one desires to tie a recursive knot and is stymied by a strict data constructor. I recently encountered this problem trying to improve the implementation of `never` in the `streaming` package. The Stream type is defined thus: data Stream f m r = Step !(f (Stream f m r)) | Effect (m (Stream f m r)) | Return r It would be nice to be able to write never :: Applicative f => Stream f m r never = fix (Step . pure) Unfortunately, if `pure` is strict (e.g., Identity), this won't work. The Step wrapper attempts to force `pure never` and then apply the Step worker. This will never work. The streaming package works around the problem by representing the `never` stream in a different way, at the potential cost of some efficiency. In other contexts, there may be no (safe) workaround at all. This is terribly frustrating, because it seems almost possible to express what I want in Core, and even possible to express it in Haskell with a really awful unsafeCoerce. The nasty version looks like this: data StreamL f m r = StepL (f (StreamL f m r)) | EffectL (m (StreamL f m r)) | ReturnL r never :: forall f m r. Applicative f => Stream f m r never = case loop of StepL x -> x `pseq` unsafeCoerce loop where loop :: StreamL f m r loop = StepL (pure loop) in loop {-# NOINLINE loop #-} {-# NOINLINE never #-} That is, I make a copy of the Stream type, but with a lazy version of the Step constructor, I tie my knot, I make very sure that the strict field is evaluated, and then I unsafeCoerce the whole thing in a thoroughly unsupported fashion to get back to the right type. Ideally, It would be nice to get GHC to manufacture, and expose to users, bidirectional patterns that offer more access to the raw representation of a type. Basically, I want to get a bidirectional pattern for Step that: 1. Is lazy when used as a constructor (applying the "worker" constructor directly) 2. Is viewed as lazy on matching, so the strictness analysis comes out right. Using such a feature will presumably always be dangerous (unless someone does a ton of work to find an efficient way to make it safe), but I'd rather have a reasonable dangerous way to do it than an unreasonable dangerous way, if that can be accomplished. Unfortunately, I haven't been able to think of a reasonable design for such a language feature. Does anyone else have any ideas? Or some other thought about how such things might be done? David From david at well-typed.com Sun Aug 27 05:31:37 2017 From: david at well-typed.com (David Feuer) Date: Sun, 27 Aug 2017 01:31:37 -0400 Subject: New primitive types? Message-ID: <20170827050502.76B2ABC42A@haskell.org> Atomic operations, or the lack thereof, don't seem terribly relevant to immutable Haskell constructor fields. David FeuerWell-Typed, LLP -------- Original message --------From: Carter Schonwald Date: 8/26/17 10:56 PM (GMT-05:00) To: Florian Weimer , Michal Terepeta Cc: ghc-devs Subject: Re: New primitive types? Which architectures are which? I assume you mean the dec alpha allowed atomic operations on bytes... but your phrasing is a teeny bit unclear On Sat, Aug 19, 2017 at 4:34 AM Florian Weimer wrote: > * Michal Terepeta: > > > On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald < > carter.schonwald at gmail.com> > > wrote: > >> One issue with packed fields is that on many architectures you can't > > quite do subword reads or > >> writes.  So it might not always be a win. > > > > Could you give any examples? > > Historic DEC Alpha, now long obsolete. > > It is very hard to create compliant and performant implementations of > Java 5, C 11 or C++ 11 on such architectures.  All these languages > (and their subsequent revisions) require that naturally aligned > objects can be accessed independently.  For example, you can't use a > simple read-modify-write cycle to implement a single-byte store using > word operations. > > That's why such architectures really do not have a future (or even a > present), except maybe in niche markets such as GPGPU (but even there, > things are heading towards the de-facto standard memory model). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at deneb.enyo.de Sun Aug 27 07:19:46 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 27 Aug 2017 09:19:46 +0200 Subject: New primitive types? In-Reply-To: (Carter Schonwald's message of "Sun, 27 Aug 2017 02:56:30 +0000") References: <87k220rm4v.fsf@mid.deneb.enyo.de> Message-ID: <87wp5pqxyl.fsf@mid.deneb.enyo.de> * Carter Schonwald: > Which architectures are which? > > I assume you mean the dec alpha allowed atomic operations on bytes... but > your phrasing is a teeny bit unclear Early DEC Alpha had only word access. From michal.terepeta at gmail.com Sun Aug 27 17:49:39 2017 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Sun, 27 Aug 2017 17:49:39 +0000 Subject: New primitive types? In-Reply-To: References: Message-ID: > On Thu, Aug 3, 2017 at 2:28 AM Sylvain Henry wrote: > Hi, > > I also think we should do this but it has a lot of ramifications: contant folding in Core, codegen, TH, etc. > > Also it will break codes that use primitive types directly, so maybe it's worth a ghc proposal. Ok, a short proposal sounds reasonable. I don't think this would break a lot of code - based on a few searches it seems that people don't really extract `Int#` from `Int8/Int16/Int32` (similarly with words). Or am I missing something? Thanks, Michal PS. Sorry for slow reply - I was traveling. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Aug 28 11:47:29 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 28 Aug 2017 11:47:29 +0000 Subject: Alex install failure In-Reply-To: <878ti7zjda.fsf@ben-laptop.smart-cactus.org> References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> <87lgm9yvoo.fsf@ben-laptop.smart-cactus.org> <878ti7zjda.fsf@ben-laptop.smart-cactus.org> Message-ID: | Hmm, alright then. What do the following say, | | * ps -Af | grep lockd | * ps -Af | grep portmap | * ps -Af | grep rpcbind | * mount | grep nfs | simonpj at cam-05-unx:~/tmp$ ps -Af | grep locd simonpj 20138 1184 0 12:46 pts/7 00:00:00 grep locd simonpj at cam-05-unx:~/tmp$ ps -Af | grep portmap simonpj 22601 1184 0 12:46 pts/7 00:00:00 grep portmap simonpj at cam-05-unx:~/tmp$ ps -Af | grep rpcbind root 1472 1 0 2016 ? 00:00:13 rpcbind -w simonpj 26634 1184 0 12:46 pts/7 00:00:00 grep rpcbind simonpj at cam-05-unx:~/tmp$ mount | grep nfs camresunxa02:/home on /home type nfs (rw,intr,vers=4,addr=10.190.50.19,clientaddr=10.190.108.81) | -----Original Message----- | From: Ben Gamari [mailto:ben at well-typed.com] | Sent: 25 August 2017 17:46 | To: Simon Peyton Jones | Cc: ghc-devs | Subject: RE: Alex install failure | | Simon Peyton Jones via ghc-devs writes: | | > | I have implemented this in wip/ghc-pkg-locking. Do you think you | > | could give this branch a try? If it still fails then we'll have to | > | try to debug things in-situ. | > | > Alas, no go. | > | Hmm, alright then. What do the following say, | | * ps -Af | grep lockd | * ps -Af | grep portmap | * ps -Af | grep rpcbind | * mount | grep nfs | | Cheers, | | - Ben From simonpj at microsoft.com Mon Aug 28 12:24:20 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 28 Aug 2017 12:24:20 +0000 Subject: Alex install failure In-Reply-To: References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> <87lgm9yvoo.fsf@ben-laptop.smart-cactus.org> <878ti7zjda.fsf@ben-laptop.smart-cactus.org> Message-ID: | note that you mistyped "lockd" (aka "lock daemon") as "locd" Oh, sorry about mistyping simonpj at cam-05-unx:~/tmp$ ps -Af | grep lockd root 140 2 0 2016 ? 00:00:00 [kblockd] simonpj 7882 1184 0 13:22 pts/7 00:00:00 grep lockd | also, the output of "rpcinfo -p" would be interesting to know simonpj at cam-05-unx:~/tmp$ rpcinfo -p Command 'rpcinfo' is available in '/usr/sbin/rpcinfo' The command could not be located because '/usr/sbin' is not included in the PATH environment variable. This is most likely caused by the lack of administrative privileges associated with your user account. rpcinfo: command not found | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 28 August 2017 12:51 | To: Simon Peyton Jones | Subject: Re: Alex install failure | | Simon, | | note that you mistyped "lockd" (aka "lock daemon") as "locd" | | also, the output of "rpcinfo -p" would be interesting to know | | On Mon, Aug 28, 2017 at 1:47 PM, Simon Peyton Jones via ghc-devs wrote: | > | Hmm, alright then. What do the following say, | > | | > | * ps -Af | grep lockd | > | * ps -Af | grep portmap | > | * ps -Af | grep rpcbind | > | * mount | grep nfs | > | | > | > simonpj at cam-05-unx:~/tmp$ ps -Af | grep locd | > simonpj 20138 1184 0 12:46 pts/7 00:00:00 grep locd | > | > simonpj at cam-05-unx:~/tmp$ ps -Af | grep portmap | > simonpj 22601 1184 0 12:46 pts/7 00:00:00 grep portmap | > | > simonpj at cam-05-unx:~/tmp$ ps -Af | grep rpcbind | > root 1472 1 0 2016 ? 00:00:13 rpcbind -w | > simonpj 26634 1184 0 12:46 pts/7 00:00:00 grep rpcbind | > | > simonpj at cam-05-unx:~/tmp$ mount | grep nfs camresunxa02:/home on /home | > type nfs (rw,intr,vers=4,addr=10.190.50.19,clientaddr=10.190.108.81) | > | > | -----Original Message----- | > | From: Ben Gamari [mailto:ben at well-typed.com] | > | Sent: 25 August 2017 17:46 | > | To: Simon Peyton Jones | > | Cc: ghc-devs | > | Subject: RE: Alex install failure | > | | > | Simon Peyton Jones via ghc-devs writes: | > | | > | > | I have implemented this in wip/ghc-pkg-locking. Do you think | > | you > | could give this branch a try? If it still fails then we'll | > | have to > | try to debug things in-situ. | > | > | > | > Alas, no go. | > | > | > | Hmm, alright then. What do the following say, | > | | > | * ps -Af | grep lockd | > | * ps -Af | grep portmap | > | * ps -Af | grep rpcbind | > | * mount | grep nfs | > | | > | Cheers, | > | | > | - Ben | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csi | > monpj%40microsoft.com%7C33b163bdb97f4f59d80f08d4ee0b07ea%7C72f988bf86f | > 141af91ab2d7cd011db47%7C1%7C0%7C636395178517098924&sdata=EOVdQbvvTDGP9 | > 2o8AHcVEcapHMicnVptxMCpwRPrsvE%3D&reserved=0 From ben at smart-cactus.org Mon Aug 28 12:36:09 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 28 Aug 2017 08:36:09 -0400 Subject: Alex install failure In-Reply-To: References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> <87lgm9yvoo.fsf@ben-laptop.smart-cactus.org> <878ti7zjda.fsf@ben-laptop.smart-cactus.org> Message-ID: <87y3q3yime.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > | note that you mistyped "lockd" (aka "lock daemon") as "locd" > > Oh, sorry about mistyping > > simonpj at cam-05-unx:~/tmp$ ps -Af | grep lockd > root 140 2 0 2016 ? 00:00:00 [kblockd] > simonpj 7882 1184 0 13:22 pts/7 00:00:00 grep lockd > Interesting; no lock daemon. > | also, the output of "rpcinfo -p" would be interesting to know > > simonpj at cam-05-unx:~/tmp$ rpcinfo -p > Command 'rpcinfo' is available in '/usr/sbin/rpcinfo' > The command could not be located because '/usr/sbin' is not included in the PATH environment variable. > This is most likely caused by the lack of administrative privileges associated with your user account. > rpcinfo: command not found > Silly me; are you able to run `sudo rpcinfo -p`? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Mon Aug 28 13:22:40 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 28 Aug 2017 13:22:40 +0000 Subject: Alex install failure In-Reply-To: <87y3q3yime.fsf@ben-laptop.smart-cactus.org> References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> <87lgm9yvoo.fsf@ben-laptop.smart-cactus.org> <878ti7zjda.fsf@ben-laptop.smart-cactus.org> <87y3q3yime.fsf@ben-laptop.smart-cactus.org> Message-ID: sudo rpcinfo -p program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 56434 status 100024 1 tcp 34797 status simonpj at cam-05-unx:~/code/HEAD$ | -----Original Message----- | From: Ben Gamari [mailto:ben at smart-cactus.org] | Sent: 28 August 2017 13:36 | To: Simon Peyton Jones ; Herbert Valerio Riedel | ; ghc-devs | Subject: RE: Alex install failure | | Simon Peyton Jones via ghc-devs writes: | | > | note that you mistyped "lockd" (aka "lock daemon") as "locd" | > | > Oh, sorry about mistyping | > | > simonpj at cam-05-unx:~/tmp$ ps -Af | grep lockd | > root 140 2 0 2016 ? 00:00:00 [kblockd] | > simonpj 7882 1184 0 13:22 pts/7 00:00:00 grep lockd | > | Interesting; no lock daemon. | | > | also, the output of "rpcinfo -p" would be interesting to know | > | > simonpj at cam-05-unx:~/tmp$ rpcinfo -p | > Command 'rpcinfo' is available in '/usr/sbin/rpcinfo' | > The command could not be located because '/usr/sbin' is not included in | the PATH environment variable. | > This is most likely caused by the lack of administrative privileges | associated with your user account. | > rpcinfo: command not found | > | Silly me; are you able to run `sudo rpcinfo -p`? | | Cheers, | | - Ben From ben at smart-cactus.org Mon Aug 28 17:42:41 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 28 Aug 2017 13:42:41 -0400 Subject: Alex install failure In-Reply-To: References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> <87lgm9yvoo.fsf@ben-laptop.smart-cactus.org> <878ti7zjda.fsf@ben-laptop.smart-cactus.org> <87y3q3yime.fsf@ben-laptop.smart-cactus.org> Message-ID: <87shgby4fi.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones writes: > sudo rpcinfo -p > program vers proto port service > 100000 4 tcp 111 portmapper > 100000 3 tcp 111 portmapper > 100000 2 tcp 111 portmapper > 100000 4 udp 111 portmapper > 100000 3 udp 111 portmapper > 100000 2 udp 111 portmapper > 100024 1 udp 56434 status > 100024 1 tcp 34797 status > simonpj at cam-05-unx:~/code/HEAD$ > Hmm, interesting. So it seems almost certain at this point that you are not running the lock daemon. In contrast, on an NFSv3 client that I setup I see, $ sudo rpcinfo -p program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 42146 status 100024 1 tcp 44535 status 100021 1 udp 33470 nlockmgr 100021 3 udp 33470 nlockmgr 100021 4 udp 33470 nlockmgr 100021 1 tcp 40385 nlockmgr 100021 3 tcp 40385 nlockmgr 100021 4 tcp 40385 nlockmgr Hmmm. I'll need to do some reading at this point. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Mon Aug 28 18:27:30 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 28 Aug 2017 14:27:30 -0400 Subject: Alex install failure In-Reply-To: <87shgby4fi.fsf@ben-laptop.smart-cactus.org> References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> <87lgm9yvoo.fsf@ben-laptop.smart-cactus.org> <878ti7zjda.fsf@ben-laptop.smart-cactus.org> <87y3q3yime.fsf@ben-laptop.smart-cactus.org> <87shgby4fi.fsf@ben-laptop.smart-cactus.org> Message-ID: <87pobfy2ct.fsf@ben-laptop.smart-cactus.org> Ben Gamari writes: snip > Hmmm. I'll need to do some reading at this point. > I am now able to reproduce the issue locally. Stay tuned. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From allbery.b at gmail.com Mon Aug 28 18:36:05 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 28 Aug 2017 14:36:05 -0400 Subject: Alex install failure In-Reply-To: <87shgby4fi.fsf@ben-laptop.smart-cactus.org> References: <87mv6xaxpm.fsf@ben-laptop.smart-cactus.org> <87lgm9yvoo.fsf@ben-laptop.smart-cactus.org> <878ti7zjda.fsf@ben-laptop.smart-cactus.org> <87y3q3yime.fsf@ben-laptop.smart-cactus.org> <87shgby4fi.fsf@ben-laptop.smart-cactus.org> Message-ID: On Mon, Aug 28, 2017 at 1:42 PM, Ben Gamari wrote: > Hmm, interesting. So it seems almost certain at this point that you are > not running the lock daemon. In contrast, on an NFSv3 client that I > setup I see, > This is moderately likely to be common: many people incorrectly believe the lock manager is a server-only daemon, and reliance on file locking is uncommon enough that they are rarely disabused of this belief. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Aug 28 20:57:11 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 28 Aug 2017 20:57:11 +0000 Subject: [commit: ghc] master: Adjust test suite stats (a055f24) In-Reply-To: <20170828183358.6DC243A584@ghc.haskell.org> References: <20170828183358.6DC243A584@ghc.haskell.org> Message-ID: David, are you sure we want to accept a more than 5% increase in compile time without investigation? What commit caused these increases? Maybe they are readily squashed? Generally we are trying to improve compiler perf not accept it getting worse! Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of | git at git.haskell.org | Sent: 28 August 2017 19:34 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Adjust test suite stats (a055f24) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2Fa055f240aeda538c656a59e810870e6a2ccc2db | 7%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4 | ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722& | sdata=WH8x1FkDCAmRas%2F5CIxA7PmqDj1zzfqApfyowKlGdfo%3D&reserved=0 | | >--------------------------------------------------------------- | | commit a055f240aeda538c656a59e810870e6a2ccc2db7 | Author: David Feuer | Date: Mon Aug 28 14:35:19 2017 -0400 | | Adjust test suite stats | | T1969 and T12150 were failing (stat too high) | | | >--------------------------------------------------------------- | | a055f240aeda538c656a59e810870e6a2ccc2db7 | testsuite/tests/perf/compiler/all.T | 6 ++++-- | 1 file changed, 4 insertions(+), 2 deletions(-) | | diff --git a/testsuite/tests/perf/compiler/all.T | b/testsuite/tests/perf/compiler/all.T | index 1da2883..cf49981 100644 | --- a/testsuite/tests/perf/compiler/all.T | +++ b/testsuite/tests/perf/compiler/all.T | @@ -72,7 +72,7 @@ test('T1969', | # 2017-03-24 9261052 (x86/Linux, 64-bit machine) | # 2017-04-06 9418680 (x86/Linux, 64-bit machine) | | - (wordsize(64), 16679176, 15)]), | + (wordsize(64), 19199872, 15)]), | # 2014-09-10 10463640, 10 # post-AMP-update (somewhat | stabelish) | # looks like the peak is around ~10M, but we're | # unlikely to GC exactly on the peak. | @@ -87,6 +87,7 @@ test('T1969', | # 2017-02-01 19924328 (amd64/Linux) Join points (#12988) | # 2017-02-14 16393848 Early inline patch | # 2017-03-31 16679176 Fix memory leak in simplifier | + # 2017-08-25 19199872 Refactor the Mighty Simplifier | | compiler_stats_num_field('bytes allocated', | [(platform('i386-unknown-mingw32'), 301784492, 5), @@ -1110,7 | +1111,8 @@ test('T12150', | [ only_ways(['optasm']), | compiler_stats_num_field('bytes allocated', | [(wordsize(64), 70773000, 5) | - # initial: 70773000 | + # initial: 70773000 | + # 2017-08-25: 74358208 Refactor the Mighty Simplifier | ]), | ], | compile, | | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4 | ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722& | sdata=j5wIO8m%2FgR3czmSfjpJlzV4HcMbwrI3nU2C98OmMkV0%3D&reserved=0 From david at well-typed.com Mon Aug 28 21:13:27 2017 From: david at well-typed.com (David Feuer) Date: Mon, 28 Aug 2017 17:13:27 -0400 Subject: [commit: ghc] master: Adjust test suite stats (a055f24) Message-ID: <20170828204650.81C67BC910@haskell.org> These were regressions from your simplifier refactoring. Yes, we should investigate. I'll open a ticket this evening, unless someone else gets to it first. But we surely don't want to keep CI red on every commit until then. David FeuerWell-Typed, LLP -------- Original message --------From: Simon Peyton Jones via ghc-devs Date: 8/28/17 4:57 PM (GMT-05:00) To: ghc-devs at haskell.org Subject: RE: [commit: ghc] master: Adjust test suite stats (a055f24) David, are you sure we want to accept a more than 5% increase in compile time without investigation?   What commit caused these increases?  Maybe they are readily squashed? Generally we are trying to improve compiler perf not accept it getting worse! Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of | git at git.haskell.org | Sent: 28 August 2017 19:34 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Adjust test suite stats (a055f24) | | Repository : ssh://git at git.haskell.org/ghc | | On branch  : master | Link       : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2Fa055f240aeda538c656a59e810870e6a2ccc2db | 7%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4 | ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722& | sdata=WH8x1FkDCAmRas%2F5CIxA7PmqDj1zzfqApfyowKlGdfo%3D&reserved=0 | | >--------------------------------------------------------------- | | commit a055f240aeda538c656a59e810870e6a2ccc2db7 | Author: David Feuer | Date:   Mon Aug 28 14:35:19 2017 -0400 | |     Adjust test suite stats | |     T1969 and T12150 were failing (stat too high) | | | >--------------------------------------------------------------- | | a055f240aeda538c656a59e810870e6a2ccc2db7 |  testsuite/tests/perf/compiler/all.T | 6 ++++-- |  1 file changed, 4 insertions(+), 2 deletions(-) | | diff --git a/testsuite/tests/perf/compiler/all.T | b/testsuite/tests/perf/compiler/all.T | index 1da2883..cf49981 100644 | --- a/testsuite/tests/perf/compiler/all.T | +++ b/testsuite/tests/perf/compiler/all.T | @@ -72,7 +72,7 @@ test('T1969', |               # 2017-03-24 9261052 (x86/Linux, 64-bit machine) |               # 2017-04-06 9418680 (x86/Linux, 64-bit machine) | | -           (wordsize(64), 16679176, 15)]), | +           (wordsize(64), 19199872, 15)]), |               # 2014-09-10 10463640, 10  # post-AMP-update (somewhat | stabelish) |                 # looks like the peak is around ~10M, but we're |                 # unlikely to GC exactly on the peak. | @@ -87,6 +87,7 @@ test('T1969', |               # 2017-02-01 19924328 (amd64/Linux) Join points (#12988) |               # 2017-02-14 16393848 Early inline patch |               # 2017-03-31 16679176 Fix memory leak in simplifier | +             # 2017-08-25 19199872 Refactor the Mighty Simplifier | |        compiler_stats_num_field('bytes allocated', |            [(platform('i386-unknown-mingw32'), 301784492, 5), @@ -1110,7 | +1111,8 @@ test('T12150', |       [ only_ways(['optasm']), |         compiler_stats_num_field('bytes allocated', |            [(wordsize(64), 70773000, 5) | -          # initial:  70773000 | +          # initial:    70773000 | +          # 2017-08-25: 74358208  Refactor the Mighty Simplifier |            ]), |       ], |      compile, | | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4 | ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722& | sdata=j5wIO8m%2FgR3czmSfjpJlzV4HcMbwrI3nU2C98OmMkV0%3D&reserved=0 _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Aug 28 21:16:25 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 28 Aug 2017 21:16:25 +0000 Subject: [commit: ghc] master: Adjust test suite stats (a055f24) In-Reply-To: <20170828204650.81C67BC910@haskell.org> References: <20170828204650.81C67BC910@haskell.org> Message-ID: Ha! They didn’t regress for me. I validated before committing. How strange. I agree about keeping it green Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David Feuer Sent: 28 August 2017 22:13 To: ghc-devs Subject: RE: [commit: ghc] master: Adjust test suite stats (a055f24) These were regressions from your simplifier refactoring. Yes, we should investigate. I'll open a ticket this evening, unless someone else gets to it first. But we surely don't want to keep CI red on every commit until then. David Feuer Well-Typed, LLP -------- Original message -------- From: Simon Peyton Jones via ghc-devs > Date: 8/28/17 4:57 PM (GMT-05:00) To: ghc-devs at haskell.org Subject: RE: [commit: ghc] master: Adjust test suite stats (a055f24) David, are you sure we want to accept a more than 5% increase in compile time without investigation? What commit caused these increases? Maybe they are readily squashed? Generally we are trying to improve compiler perf not accept it getting worse! Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of | git at git.haskell.org | Sent: 28 August 2017 19:34 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Adjust test suite stats (a055f24) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2Fa055f240aeda538c656a59e810870e6a2ccc2db | 7%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4 | ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722& | sdata=WH8x1FkDCAmRas%2F5CIxA7PmqDj1zzfqApfyowKlGdfo%3D&reserved=0 | | >--------------------------------------------------------------- | | commit a055f240aeda538c656a59e810870e6a2ccc2db7 | Author: David Feuer > | Date: Mon Aug 28 14:35:19 2017 -0400 | | Adjust test suite stats | | T1969 and T12150 were failing (stat too high) | | | >--------------------------------------------------------------- | | a055f240aeda538c656a59e810870e6a2ccc2db7 | testsuite/tests/perf/compiler/all.T | 6 ++++-- | 1 file changed, 4 insertions(+), 2 deletions(-) | | diff --git a/testsuite/tests/perf/compiler/all.T | b/testsuite/tests/perf/compiler/all.T | index 1da2883..cf49981 100644 | --- a/testsuite/tests/perf/compiler/all.T | +++ b/testsuite/tests/perf/compiler/all.T | @@ -72,7 +72,7 @@ test('T1969', | # 2017-03-24 9261052 (x86/Linux, 64-bit machine) | # 2017-04-06 9418680 (x86/Linux, 64-bit machine) | | - (wordsize(64), 16679176, 15)]), | + (wordsize(64), 19199872, 15)]), | # 2014-09-10 10463640, 10 # post-AMP-update (somewhat | stabelish) | # looks like the peak is around ~10M, but we're | # unlikely to GC exactly on the peak. | @@ -87,6 +87,7 @@ test('T1969', | # 2017-02-01 19924328 (amd64/Linux) Join points (#12988) | # 2017-02-14 16393848 Early inline patch | # 2017-03-31 16679176 Fix memory leak in simplifier | + # 2017-08-25 19199872 Refactor the Mighty Simplifier | | compiler_stats_num_field('bytes allocated', | [(platform('i386-unknown-mingw32'), 301784492, 5), @@ -1110,7 | +1111,8 @@ test('T12150', | [ only_ways(['optasm']), | compiler_stats_num_field('bytes allocated', | [(wordsize(64), 70773000, 5) | - # initial: 70773000 | + # initial: 70773000 | + # 2017-08-25: 74358208 Refactor the Mighty Simplifier | ]), | ], | compile, | | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4 | ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722& | sdata=j5wIO8m%2FgR3czmSfjpJlzV4HcMbwrI3nU2C98OmMkV0%3D&reserved=0 _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Tue Aug 29 15:45:37 2017 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Tue, 29 Aug 2017 16:45:37 +0100 Subject: Crossreferenced GHC 8.0.2 In-Reply-To: References: Message-ID: On 17/08/17 18:22, Matthew Pickering wrote: > 2. A nix function which builds and references all dependencies. Very nice, it worked out of the box for me! (Almost, small issue with https://github.com/mpickering/core-kythe/issues/10.) I like how you can just add package names to a file and everything magically works without setup effort. Niklas From lonetiger at gmail.com Tue Aug 29 22:25:02 2017 From: lonetiger at gmail.com (lonetiger at gmail.com) Date: Tue, 29 Aug 2017 23:25:02 +0100 Subject: dll-split Message-ID: <59a5e9bf.0f151c0a.b8127.5db6@mx.google.com> Hi All, I have just killed off dll-split, this means that you no longer need to maintain a list of modules in GHC.mk. If you’re a non-Windows programmer you can stop reading here, for those that build on Windows: The replacement for dll-split is called gen-dll, and it is able to automatically partition any library we build, so this issue is hopefully solved once and for all. Currently dynamic linking is still turned off as I have a few more patches to upstream. When I do turn it on, by default you will get a large ~45min hit in compile time. This is because dlltool which BFD based is quite slow. To mitigate this gen-dll supports the use of the msys2 project’s genlib tool. This tool finishes in seconds instead of tens of minutes like dlltool. To install it just run pacman -Sy mingw-w64-$(uname -m)-tools-git The wiki pages have been updated accordingly already. If you install this now you won’t notice any difference in build time later. Thanks, Tamar -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Wed Aug 30 14:19:32 2017 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 30 Aug 2017 10:19:32 -0400 Subject: dll-split Message-ID: Thanks for putting so much effort into this work, Tamar! > When I do turn it on, by default you will get a large ~45min hit in compile time. Yikes, that's really bad! Bad enough that I have to wonder: would it be worth including genlib among the other executables that we bundle with GHC? Fortunately, us GHC developers have the foresight to know that we should install genlib, but I imagine less informed Windows users probably won't get the memo and will start to wonder why compilation became so slow all of a sudden. Ryan S. From me at ara.io Wed Aug 30 14:24:57 2017 From: me at ara.io (Ara Adkins) Date: Wed, 30 Aug 2017 15:24:57 +0100 Subject: dll-split In-Reply-To: References: Message-ID: With a hit like that I think it should at least be highly publicised that it can cause huge hits to compilation time. I would support bundling the executable if it has a compatible license. _ara On Wed, Aug 30, 2017 at 3:19 PM, Ryan Scott wrote: > Thanks for putting so much effort into this work, Tamar! > > > When I do turn it on, by default you will get a large ~45min hit in > compile time. > > Yikes, that's really bad! Bad enough that I have to wonder: would it > be worth including genlib among the other executables that we bundle > with GHC? Fortunately, us GHC developers have the foresight to know > that we should install genlib, but I imagine less informed Windows > users probably won't get the memo and will start to wonder why > compilation became so slow all of a sudden. > > Ryan S. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Wed Aug 30 17:28:22 2017 From: lonetiger at gmail.com (Phyx) Date: Wed, 30 Aug 2017 17:28:22 +0000 Subject: dll-split In-Reply-To: References: Message-ID: That's certainly a possibility, though note that this is only an issue for compiling stage2, not end user programs. Since it's only for compiling ghc we don't have to include it in the bindist so license would be less of an issue I think. I'll modify the scripts to pull it automatically when I submit the rest of the patches. Thanks, Tamar On Wed, Aug 30, 2017 at 3:25 PM Ara Adkins wrote: > With a hit like that I think it should at least be highly publicised that > it can cause huge hits to compilation time. I would support bundling the > executable if it has a compatible license. > > _ara > > On Wed, Aug 30, 2017 at 3:19 PM, Ryan Scott > wrote: > >> Thanks for putting so much effort into this work, Tamar! >> >> > When I do turn it on, by default you will get a large ~45min hit in >> compile time. >> >> Yikes, that's really bad! Bad enough that I have to wonder: would it >> be worth including genlib among the other executables that we bundle >> with GHC? Fortunately, us GHC developers have the foresight to know >> that we should install genlib, but I imagine less informed Windows >> users probably won't get the memo and will start to wonder why >> compilation became so slow all of a sudden. >> >> Ryan S. >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at ara.io Wed Aug 30 17:37:01 2017 From: me at ara.io (Ara Adkins) Date: Wed, 30 Aug 2017 18:37:01 +0100 Subject: dll-split In-Reply-To: References: Message-ID: That’s a very good point, and should be a good solution for now. _ara > On 30 Aug 2017, at 18:28, Phyx wrote: > > That's certainly a possibility, though note that this is only an issue for compiling stage2, not end user programs. > Since it's only for compiling ghc we don't have to include it in the bindist so license would be less of an issue I think. > > I'll modify the scripts to pull it automatically when I submit the rest of the patches. > > Thanks, > Tamar > >> On Wed, Aug 30, 2017 at 3:25 PM Ara Adkins wrote: >> With a hit like that I think it should at least be highly publicised that it can cause huge hits to compilation time. I would support bundling the executable if it has a compatible license. >> >> _ara >> >>> On Wed, Aug 30, 2017 at 3:19 PM, Ryan Scott wrote: >>> Thanks for putting so much effort into this work, Tamar! >>> >>> > When I do turn it on, by default you will get a large ~45min hit in compile time. >>> >>> Yikes, that's really bad! Bad enough that I have to wonder: would it >>> be worth including genlib among the other executables that we bundle >>> with GHC? Fortunately, us GHC developers have the foresight to know >>> that we should install genlib, but I imagine less informed Windows >>> users probably won't get the memo and will start to wonder why >>> compilation became so slow all of a sudden. >>> >>> Ryan S. >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at well-typed.com Thu Aug 31 19:37:15 2017 From: david at well-typed.com (David Feuer) Date: Thu, 31 Aug 2017 15:37:15 -0400 Subject: Type-level generics Message-ID: <8748542.10fH5JaPFX@squirrel> I've been thinking for several weeks that it might be useful to offer type-level generics. That is, along with to :: Rep a k -> a from :: a -> Rep a perhaps we should also derive type family To (r :: Rep a x) :: a type family From (v :: a) :: Rep a x This would allow us to use generic programming at the type level For example, we could write a generic ordering family: class OrdK (k :: Type) where type Compare (x :: k) (y :: k) :: Ordering type Compare (x :: k) (y :: k) = GenComp (Rep k ()) (From x) (From y) instance OrdK Nat where type Compare x y = CmpNat x y instance OrdK Symbol where type Compare x y = CmpSymbol x y instance OrdK [a] -- No implementation needed! type family GenComp k (x :: k) (y :: k) :: Ordering where GenComp (M1 i c f p) ('M1 x) ('M1 y) = GenComp (f p) x y GenComp (K1 i c p) ('K1 x) ('K1 y) = Compare x y GenComp ((x :+: y) p) ('L1 m) ('L1 n) = GenComp (x p) m n GenComp ((x :+: y) p) ('R1 m) ('R1 n) = GenComp (y p) m n GenComp ((x :+: y) p) ('L1 _) ('R1 _) = 'LT GenComp ((x :+: y) p) ('R1 _) ('L1 _) = 'GT GenComp ((x :*: y) p) (x1 ':*: y1) (x2 ':*: y2) = PComp (GenComp (x p) x1 x2) (y p) y1 y2 GenComp (U1 p) _ _ = 'EQ GenComp (V1 p) _ _ = 'EQ type family PComp (c :: Ordering) k (x :: k) (y :: k) :: Ordering where PComp 'EQ k x y = GenComp k x y PComp x _ _ _ = x For people who want to play around with the idea, here are the definitions of To and From for lists: To ('M1 ('L1 ('M1 'U1))) = '[] To ('M1 ('R1 ('M1 ('M1 ('K1 x) ':*: 'M1 ('K1 xs))))) = x ': xs From '[] = 'M1 ('L1 ('M1 'U1)) From (x ': xs) = 'M1 ('R1 ('M1 ('M1 ('K1 x) ':*: 'M1 ('K1 xs)))) David From david at well-typed.com Thu Aug 31 20:22:23 2017 From: david at well-typed.com (David Feuer) Date: Thu, 31 Aug 2017 16:22:23 -0400 Subject: Type-level generics In-Reply-To: <8748542.10fH5JaPFX@squirrel> References: <8748542.10fH5JaPFX@squirrel> Message-ID: <2360843.yIA53fhjkg@squirrel> One other thing I should add. We'd really, really like to have isomorphism evidence: toThenFrom :: pr p -> To (From x :: Rep a p) :~: (x :: a) fromThenTo :: pr1 a -> pr2 (r :: Rep a p) -> From (To r :: a) :~: (r :: Rep a p) I believe these would make the To and From families considerably more useful. Unfortunately, while I'm pretty sure those are completely legit for any Generic-derived types, I don't think there's ever any way to prove them in Haskell! Ugh. On Thursday, August 31, 2017 3:37:15 PM EDT David Feuer wrote: > I've been thinking for several weeks that it might be useful to offer > type-level generics. That is, along with > > to :: Rep a k -> a > from :: a -> Rep a > > perhaps we should also derive > > type family To (r :: Rep a x) :: a > type family From (v :: a) :: Rep a x > > This would allow us to use generic programming at the type level > For example, we could write a generic ordering family: > > class OrdK (k :: Type) where > type Compare (x :: k) (y :: k) :: Ordering > type Compare (x :: k) (y :: k) = GenComp (Rep k ()) (From x) (From y) > > instance OrdK Nat where > type Compare x y = CmpNat x y > > instance OrdK Symbol where > type Compare x y = CmpSymbol x y > > instance OrdK [a] -- No implementation needed! > > type family GenComp k (x :: k) (y :: k) :: Ordering where > GenComp (M1 i c f p) ('M1 x) ('M1 y) = GenComp (f p) x y > GenComp (K1 i c p) ('K1 x) ('K1 y) = Compare x y > GenComp ((x :+: y) p) ('L1 m) ('L1 n) = GenComp (x p) m n > GenComp ((x :+: y) p) ('R1 m) ('R1 n) = GenComp (y p) m n > GenComp ((x :+: y) p) ('L1 _) ('R1 _) = 'LT > GenComp ((x :+: y) p) ('R1 _) ('L1 _) = 'GT > GenComp ((x :*: y) p) (x1 ':*: y1) (x2 ':*: y2) = > PComp (GenComp (x p) x1 x2) (y p) y1 y2 > GenComp (U1 p) _ _ = 'EQ > GenComp (V1 p) _ _ = 'EQ > > type family PComp (c :: Ordering) k (x :: k) (y :: k) :: Ordering where > PComp 'EQ k x y = GenComp k x y > PComp x _ _ _ = x > > For people who want to play around with the idea, here are the definitions of To and From > for lists: > > To ('M1 ('L1 ('M1 'U1))) = '[] > To ('M1 ('R1 ('M1 ('M1 ('K1 x) ':*: 'M1 ('K1 xs))))) = x ': xs > From '[] = 'M1 ('L1 ('M1 'U1)) > From (x ': xs) = 'M1 ('R1 ('M1 ('M1 ('K1 x) ':*: 'M1 ('K1 xs)))) > > David