From harendra.kumar at gmail.com Mon Feb 5 03:50:52 2018 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Mon, 5 Feb 2018 09:20:52 +0530 Subject: rolling span and groupBy for lists Message-ID: Hi, For a small problem, I was looking for a groupBy like function that groups based on a predicate on successive elements but I could not find one. I wrote these little functions for that purpose: -- | Like span, but with a predicate that compares two successive elements. The -- span ends when the two successive elements do not satisfy the predicate. rollingSpan :: (a -> a -> Bool) -> [a] -> ([a], [a]) rollingSpan _ xs@[] = (xs, xs) rollingSpan _ xs@[_] = (xs, []) rollingSpan p (x1:xs@(x2:_)) | p x1 x2 = let (ys, zs) = rollingSpan p xs in (x1 : ys, zs) | otherwise = ([x1], xs) -- | Like 'groupBy' but with a predicate that compares two successive elements. -- A group ends when two successive elements do not satisfy the predicate. rollingGroupBy :: (a -> a -> Bool) -> [a] -> [[a]] rollingGroupBy _ [] = [] rollingGroupBy cmp xs = let (ys, zs) = rollingSpan cmp xs in ys : rollingGroupBy cmp zs Are there any existing functions that serve this purpose or is there any simpler way to achieve such functionality? If not, where is the right place for these, if any. Can they be included in Data.List in base? Thanks, Harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at well-typed.com Mon Feb 5 04:23:44 2018 From: david at well-typed.com (David Feuer) Date: Sun, 04 Feb 2018 23:23:44 -0500 Subject: rolling span and groupBy for lists In-Reply-To: Message-ID: <20180205035037.E3C1ABCD73@haskell.org> This is the wrong list. You probably meant to email haskell-cafe or perhaps libraries at haskell.org. David FeuerWell-Typed, LLP -------- Original message --------From: Harendra Kumar Date: 2/4/18 10:50 PM (GMT-05:00) To: ghc-devs at haskell.org Subject: rolling span and groupBy for lists Hi, For a small problem, I was looking for a groupBy like function that groups based on a predicate on successive elements but I could not find one. I wrote these little functions for that purpose: -- | Like span, but with a predicate that compares two successive elements. The -- span ends when the two successive elements do not satisfy the predicate. rollingSpan :: (a -> a -> Bool) -> [a] -> ([a], [a]) rollingSpan _ xs@[] = (xs, xs) rollingSpan _ xs@[_] = (xs, []) rollingSpan p (x1:xs@(x2:_))     | p x1 x2 =         let (ys, zs) = rollingSpan p xs         in (x1 : ys, zs)     | otherwise = ([x1], xs) -- | Like 'groupBy' but with a predicate that compares two successive elements. -- A group ends when two successive elements do not satisfy the predicate. rollingGroupBy :: (a -> a -> Bool) -> [a] -> [[a]] rollingGroupBy _ [] = [] rollingGroupBy cmp xs =     let (ys, zs) = rollingSpan cmp xs     in ys : rollingGroupBy cmp zs Are there any existing functions that serve this purpose or is there any simpler way to achieve such functionality? If not, where is the right place for these, if any. Can they be included in Data.List in base? Thanks, Harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Mon Feb 5 04:37:55 2018 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Mon, 5 Feb 2018 10:07:55 +0530 Subject: rolling span and groupBy for lists In-Reply-To: <5a77dc55.c1e51c0a.9c3d1.a88bSMTPIN_ADDED_MISSING@mx.google.com> References: <5a77dc55.c1e51c0a.9c3d1.a88bSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: I was mainly asking if it makes sense to include these functions in base/Data.List. Since the base package is maintained and ships along with ghc, and the issues are also raised at ghc trac I thought this is the right list. I am copying to libraries at haskell.org as well. -harendra On 5 February 2018 at 09:53, David Feuer wrote: > This is the wrong list. You probably meant to email haskell-cafe or > perhaps libraries at haskell.org. > > > > David Feuer > Well-Typed, LLP > > -------- Original message -------- > From: Harendra Kumar > Date: 2/4/18 10:50 PM (GMT-05:00) > To: ghc-devs at haskell.org > Subject: rolling span and groupBy for lists > > Hi, > > For a small problem, I was looking for a groupBy like function that groups > based on a predicate on successive elements but I could not find one. I > wrote these little functions for that purpose: > > -- | Like span, but with a predicate that compares two successive elements. > The > -- span ends when the two successive elements do not satisfy the predicate. > rollingSpan :: (a -> a -> Bool) -> [a] -> ([a], [a]) > rollingSpan _ xs@[] = (xs, xs) > rollingSpan _ xs@[_] = (xs, []) > rollingSpan p (x1:xs@(x2:_)) > | p x1 x2 = > let (ys, zs) = rollingSpan p xs > in (x1 : ys, zs) > | otherwise = ([x1], xs) > > -- | Like 'groupBy' but with a predicate that compares two successive > elements. > -- A group ends when two successive elements do not satisfy the predicate. > rollingGroupBy :: (a -> a -> Bool) -> [a] -> [[a]] > rollingGroupBy _ [] = [] > rollingGroupBy cmp xs = > let (ys, zs) = rollingSpan cmp xs > in ys : rollingGroupBy cmp zs > > Are there any existing functions that serve this purpose or is there any > simpler way to achieve such functionality? If not, where is the right place > for these, if any. Can they be included in Data.List in base? > > Thanks, > Harendra > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Mon Feb 5 06:52:08 2018 From: qdunkan at gmail.com (Evan Laforge) Date: Sun, 4 Feb 2018 22:52:08 -0800 Subject: rolling span and groupBy for lists In-Reply-To: References: Message-ID: I have my own list library with a bunch of things like this. I think it's what most people do, and some upload them to hackage, e.g. utility-ht or the split package, or data-ordlist. Specifically, I think rollingGroupBy is what I call splitWith: -- | Split @xs@ before places where @f@ matches. -- -- > split_with (==1) [1,2,1] -- > --> [[], [1, 2], [1]] split_with :: (a -> Bool) -> [a] -> NonNull [a] -- ^ output is non-null, and the contents are also, except the first one You can probably find something like this in 'split', or if not, that might be a good place to contribute it. I have a bunch of grouping functions too, which I use all the time, so if there's some kind of general list grouping package then maybe I could put them there. On the other hand, this sort of thing is pretty individual, so it doesn't seem so bad for each person to have their own local library. That way you know it fits your style. Ultimately I think that's why none of the split functions made it into Data.List, every person has a slightly different idea of what it should be. On Sun, Feb 4, 2018 at 7:50 PM, Harendra Kumar wrote: > Hi, > > For a small problem, I was looking for a groupBy like function that groups > based on a predicate on successive elements but I could not find one. I > wrote these little functions for that purpose: > > -- | Like span, but with a predicate that compares two successive elements. > The > -- span ends when the two successive elements do not satisfy the predicate. > rollingSpan :: (a -> a -> Bool) -> [a] -> ([a], [a]) > rollingSpan _ xs@[] = (xs, xs) > rollingSpan _ xs@[_] = (xs, []) > rollingSpan p (x1:xs@(x2:_)) > | p x1 x2 = > let (ys, zs) = rollingSpan p xs > in (x1 : ys, zs) > | otherwise = ([x1], xs) > > -- | Like 'groupBy' but with a predicate that compares two successive > elements. > -- A group ends when two successive elements do not satisfy the predicate. > rollingGroupBy :: (a -> a -> Bool) -> [a] -> [[a]] > rollingGroupBy _ [] = [] > rollingGroupBy cmp xs = > let (ys, zs) = rollingSpan cmp xs > in ys : rollingGroupBy cmp zs > > Are there any existing functions that serve this purpose or is there any > simpler way to achieve such functionality? If not, where is the right place > for these, if any. Can they be included in Data.List in base? > > Thanks, > Harendra > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From tkn.akio at gmail.com Mon Feb 5 07:06:51 2018 From: tkn.akio at gmail.com (Akio Takano) Date: Mon, 5 Feb 2018 07:06:51 +0000 Subject: The BlockArguments extension has been added to Cabal Message-ID: Dear GHC devs, The new `BlockArguments` extension has been added to the Cabal library. I'm sending out this notification because the Note [Adding a language extension] in compiler/main/DynFlags.hs asks me to do so. Regards, Takano Akio From simonpj at microsoft.com Mon Feb 5 11:19:24 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 5 Feb 2018 11:19:24 +0000 Subject: [commit: ghc] master: Hoopl.Collections: change right folds to strict left folds (2974b2b) In-Reply-To: <20180203005629.80D0F3A5EE@ghc.haskell.org> References: <20180203005629.80D0F3A5EE@ghc.haskell.org> Message-ID: Hi Michael Thanks for pushing forward with Hoopl and other back-end things. Did this patch elicit any performance gains? Or what brought it to your attention? Do you have further plans for Hoopl and GHC's back end? Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf | Of git at git.haskell.org | Sent: 03 February 2018 00:56 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Hoopl.Collections: change right folds | to strict left folds (2974b2b) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha | skell.org%2Ftrac%2Fghc%2Fchangeset%2F2974b2b873b4bad007c619c6e32706123 | a612428%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C19a7af179b224ee | 8b74708d56aa0fa00%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C6365321 | 61979971135&sdata=muRQGh3GHuEirDVMUgTb0JKbBUkvqceymKFQTt9eAY0%3D&reser | ved=0 | | >--------------------------------------------------------------- | | commit 2974b2b873b4bad007c619c6e32706123a612428 | Author: Michal Terepeta | Date: Thu Feb 1 00:30:22 2018 -0500 | | Hoopl.Collections: change right folds to strict left folds | | It seems that most uses of these folds should be strict left folds | (I could only find a single place that benefits from a right | fold). | So this removes the existing `setFold`/`mapFold`/`mapFoldWihKey` | replaces them with: | - `setFoldl`/`mapFoldl`/`mapFoldlWithKey` (strict left folds) | - `setFoldr`/`mapFoldr` (for the less common case where a right | fold | actually makes sense, e.g., `CmmProcPoint`) | | Signed-off-by: Michal Terepeta | | Test Plan: ./validate | | Reviewers: bgamari, simonmar | | Reviewed By: bgamari | | Subscribers: rwbarton, thomie, carter, kavon | | Differential Revision: https://phabricator.haskell.org/D4356 | | | >--------------------------------------------------------------- | | 2974b2b873b4bad007c619c6e32706123a612428 | compiler/cmm/CmmCommonBlockElim.hs | 4 ++-- | compiler/cmm/CmmContFlowOpt.hs | 6 +++--- | compiler/cmm/CmmProcPoint.hs | 20 ++++++++++---------- | compiler/cmm/CmmUtils.hs | 6 +++--- | compiler/cmm/Hoopl/Collections.hs | 16 ++++++++++------ | compiler/cmm/Hoopl/Dataflow.hs | 8 ++++---- | compiler/cmm/Hoopl/Graph.hs | 6 +++--- | compiler/cmm/Hoopl/Label.hs | 9 ++++++--- | compiler/nativeGen/RegAlloc/Graph/Spill.hs | 9 ++++----- | 9 files changed, 45 insertions(+), 39 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | 2974b2b873b4bad007c619c6e32706123a612428 | _______________________________________________ | 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=02%7C01%7Csimonpj%40microsoft.com%7C19a7af179b224ee8b7470 | 8d56aa0fa00%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C6365321619799 | 71135&sdata=hSeyqtbepopL%2FkSme3DPLOQQKf9WCLWsdVMh86tbx4o%3D&reserved= | 0 From harendra.kumar at gmail.com Mon Feb 5 15:43:53 2018 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Mon, 5 Feb 2018 21:13:53 +0530 Subject: rolling span and groupBy for lists In-Reply-To: References: Message-ID: On 5 February 2018 at 12:22, Evan Laforge wrote: > I have my own list library with a bunch of things like this. I think > it's what most people do, and some upload them to hackage, e.g. > utility-ht or the split package, or data-ordlist. > The irony is that theoretically you can find a Haskell package or implementation of whatever you can imagine but quite often it takes more time to discover it than writing your own. And then uploading what you wrote to hackage compounds the problem. A hoogle search only shows the groupBy in base, signature search also does not yield other results, it seems hoogle does not cover those other packages. After writing my own and spending quite a bit of time I could find two other similar implementations of groupBy, one in "utility-ht" package and the other in "data-list-sequences" but they don't turn up in hoogle search. It looks like hoogle database should cover more packages, or maybe the search has some issues. This state of affairs encourages people to write their own rather than find and reuse stuff. My example in this email can be dismissed as a small one but I think it is a larger problem. > You can probably find something like this in 'split', or if not, that > might be a good place to contribute it. > Yes, that is the fallback option I was considering, split seems to be the most comprehensive of all such list related packages. > I have a bunch of grouping functions too, which I use all the time, so > if there's some kind of general list grouping package then maybe I > could put them there. > It will be a great service to other Haskell explorers if we can consolidate all such packages and make one standard package covering most use cases and deprecate the other packages. Also it may be a good idea to have a see-also or related packages kind of field in packages so that discovery is easy. > On the other hand, this sort of thing is pretty individual, so it > doesn't seem so bad for each person to have their own local library. > That way you know it fits your style. Ultimately I think that's why > none of the split functions made it into Data.List, every person has a > slightly different idea of what it should be. > I thought that rollingGroupBy would have been a better default option as it can practically subsume the purpose of groupBy. groupBy in base is not well documented, and intuitively many think it works the way rollingGroupBy works i.e. compare two successive elements rather than comparing a fixed element. See this stack overflow question https://stackoverflow.com/questions/45654216/haskell-groupby-function-how-exactly-does-it-work , I thought the same way. I guess if we compare two successive elements, by transitive equality the existing groupBy implementation will practically get covered by that, not strictly compatible but should serve all practical purposes. That was the point why I was asking to consider having it in base alongside groupBy. It seems more useful, general and intuitive than the existing groupBy. -harendra > > On Sun, Feb 4, 2018 at 7:50 PM, Harendra Kumar > wrote: > > Hi, > > > > For a small problem, I was looking for a groupBy like function that > groups > > based on a predicate on successive elements but I could not find one. I > > wrote these little functions for that purpose: > > > > -- | Like span, but with a predicate that compares two successive > elements. > > The > > -- span ends when the two successive elements do not satisfy the > predicate. > > rollingSpan :: (a -> a -> Bool) -> [a] -> ([a], [a]) > > rollingSpan _ xs@[] = (xs, xs) > > rollingSpan _ xs@[_] = (xs, []) > > rollingSpan p (x1:xs@(x2:_)) > > | p x1 x2 = > > let (ys, zs) = rollingSpan p xs > > in (x1 : ys, zs) > > | otherwise = ([x1], xs) > > > > -- | Like 'groupBy' but with a predicate that compares two successive > > elements. > > -- A group ends when two successive elements do not satisfy the > predicate. > > rollingGroupBy :: (a -> a -> Bool) -> [a] -> [[a]] > > rollingGroupBy _ [] = [] > > rollingGroupBy cmp xs = > > let (ys, zs) = rollingSpan cmp xs > > in ys : rollingGroupBy cmp zs > > > > Are there any existing functions that serve this purpose or is there any > > simpler way to achieve such functionality? If not, where is the right > place > > for these, if any. Can they be included in Data.List in base? > > > > Thanks, > > 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 Mon Feb 5 17:30:47 2018 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Mon, 5 Feb 2018 23:00:47 +0530 Subject: [Haskell-cafe] rolling span and groupBy for lists In-Reply-To: <87tvuvs8h5.fsf@colimite.fr> References: <87tvuvs8h5.fsf@colimite.fr> Message-ID: Yes, Hayoo seems to be giving better results, I found more variants having the behavior I want, it seems this variant is quite popular but still not in any standard libraries. Interestingly the problem of too many choices and no standard one that can be discovered applies to search engines as well. In this case there are only two choices but still it is of the same nature. I knew about hayoo but forgot to use it in this case. How much time should one spend on finding a trivial function before giving up and making the choice to write their own? I wish there was a standard, quick, good quality way of discovering what to use. It seems the Haskell ecosystem DNA encourages more and more fragmentation rather than consolidation. I think the community/leaders should acknowledge this problem and work on making things better in the short/long run. -harendra On 5 February 2018 at 22:02, Sergiu Ivanov wrote: > Hello Harendra, > > Thus quoth Harendra Kumar on Mon Feb 05 2018 at 16:43 (+0100): > > > > The irony is that theoretically you can find a Haskell package or > > implementation of whatever you can imagine but quite often it takes more > > time to discover it than writing your own. > > Sometimes Hayoo! helps me out in such situations: > > http://hayoo.fh-wedel.de/?query=groupBy > > utility-ht shows up. > > -- > Sergiu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Mon Feb 5 18:13:53 2018 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Mon, 5 Feb 2018 23:43:53 +0530 Subject: rolling span and groupBy for lists In-Reply-To: References: Message-ID: According to hayoo there seem to be 7 different implementations of this same function. Yours is 8th and mine is 9th and other people may have more not uploaded or maybe the ones that hayoo is not able to find. Does that make a case for including this in some standard place? -harendra On 5 February 2018 at 12:22, Evan Laforge wrote: > I have my own list library with a bunch of things like this. I think > it's what most people do, and some upload them to hackage, e.g. > utility-ht or the split package, or data-ordlist. > > Specifically, I think rollingGroupBy is what I call splitWith: > > -- | Split @xs@ before places where @f@ matches. > -- > -- > split_with (==1) [1,2,1] > -- > --> [[], [1, 2], [1]] > split_with :: (a -> Bool) -> [a] -> NonNull [a] > -- ^ output is non-null, and the contents are also, except the first > one > > You can probably find something like this in 'split', or if not, that > might be a good place to contribute it. > > I have a bunch of grouping functions too, which I use all the time, so > if there's some kind of general list grouping package then maybe I > could put them there. > > On the other hand, this sort of thing is pretty individual, so it > doesn't seem so bad for each person to have their own local library. > That way you know it fits your style. Ultimately I think that's why > none of the split functions made it into Data.List, every person has a > slightly different idea of what it should be. > > On Sun, Feb 4, 2018 at 7:50 PM, Harendra Kumar > wrote: > > Hi, > > > > For a small problem, I was looking for a groupBy like function that > groups > > based on a predicate on successive elements but I could not find one. I > > wrote these little functions for that purpose: > > > > -- | Like span, but with a predicate that compares two successive > elements. > > The > > -- span ends when the two successive elements do not satisfy the > predicate. > > rollingSpan :: (a -> a -> Bool) -> [a] -> ([a], [a]) > > rollingSpan _ xs@[] = (xs, xs) > > rollingSpan _ xs@[_] = (xs, []) > > rollingSpan p (x1:xs@(x2:_)) > > | p x1 x2 = > > let (ys, zs) = rollingSpan p xs > > in (x1 : ys, zs) > > | otherwise = ([x1], xs) > > > > -- | Like 'groupBy' but with a predicate that compares two successive > > elements. > > -- A group ends when two successive elements do not satisfy the > predicate. > > rollingGroupBy :: (a -> a -> Bool) -> [a] -> [[a]] > > rollingGroupBy _ [] = [] > > rollingGroupBy cmp xs = > > let (ys, zs) = rollingSpan cmp xs > > in ys : rollingGroupBy cmp zs > > > > Are there any existing functions that serve this purpose or is there any > > simpler way to achieve such functionality? If not, where is the right > place > > for these, if any. Can they be included in Data.List in base? > > > > Thanks, > > 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 allbery.b at gmail.com Mon Feb 5 18:16:08 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 5 Feb 2018 13:16:08 -0500 Subject: rolling span and groupBy for lists In-Reply-To: References: Message-ID: Why do I suddenly catch a whiff of https://xkcd.com/927/ ? On Mon, Feb 5, 2018 at 1:13 PM, Harendra Kumar wrote: > According to hayoo there seem to be 7 different implementations of this > same function. Yours is 8th and mine is 9th and other people may have more > not uploaded or maybe the ones that hayoo is not able to find. Does that > make a case for including this in some standard place? > > -harendra > > On 5 February 2018 at 12:22, Evan Laforge wrote: > >> I have my own list library with a bunch of things like this. I think >> it's what most people do, and some upload them to hackage, e.g. >> utility-ht or the split package, or data-ordlist. >> >> Specifically, I think rollingGroupBy is what I call splitWith: >> >> -- | Split @xs@ before places where @f@ matches. >> -- >> -- > split_with (==1) [1,2,1] >> -- > --> [[], [1, 2], [1]] >> split_with :: (a -> Bool) -> [a] -> NonNull [a] >> -- ^ output is non-null, and the contents are also, except the first >> one >> >> You can probably find something like this in 'split', or if not, that >> might be a good place to contribute it. >> >> I have a bunch of grouping functions too, which I use all the time, so >> if there's some kind of general list grouping package then maybe I >> could put them there. >> >> On the other hand, this sort of thing is pretty individual, so it >> doesn't seem so bad for each person to have their own local library. >> That way you know it fits your style. Ultimately I think that's why >> none of the split functions made it into Data.List, every person has a >> slightly different idea of what it should be. >> >> On Sun, Feb 4, 2018 at 7:50 PM, Harendra Kumar >> wrote: >> > Hi, >> > >> > For a small problem, I was looking for a groupBy like function that >> groups >> > based on a predicate on successive elements but I could not find one. I >> > wrote these little functions for that purpose: >> > >> > -- | Like span, but with a predicate that compares two successive >> elements. >> > The >> > -- span ends when the two successive elements do not satisfy the >> predicate. >> > rollingSpan :: (a -> a -> Bool) -> [a] -> ([a], [a]) >> > rollingSpan _ xs@[] = (xs, xs) >> > rollingSpan _ xs@[_] = (xs, []) >> > rollingSpan p (x1:xs@(x2:_)) >> > | p x1 x2 = >> > let (ys, zs) = rollingSpan p xs >> > in (x1 : ys, zs) >> > | otherwise = ([x1], xs) >> > >> > -- | Like 'groupBy' but with a predicate that compares two successive >> > elements. >> > -- A group ends when two successive elements do not satisfy the >> predicate. >> > rollingGroupBy :: (a -> a -> Bool) -> [a] -> [[a]] >> > rollingGroupBy _ [] = [] >> > rollingGroupBy cmp xs = >> > let (ys, zs) = rollingSpan cmp xs >> > in ys : rollingGroupBy cmp zs >> > >> > Are there any existing functions that serve this purpose or is there any >> > simpler way to achieve such functionality? If not, where is the right >> place >> > for these, if any. Can they be included in Data.List in base? >> > >> > Thanks, >> > Harendra >> > >> > _______________________________________________ >> > 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 > > -- 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 harendra.kumar at gmail.com Mon Feb 5 18:22:19 2018 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Mon, 5 Feb 2018 23:52:19 +0530 Subject: rolling span and groupBy for lists In-Reply-To: References: Message-ID: Yes, I did too :-) But there is a key difference in this case, all these definitions are mathematically equivalent with identical semantics instead of being some fuzzy subjective standards. -harendra On 5 February 2018 at 23:46, Brandon Allbery wrote: > Why do I suddenly catch a whiff of https://xkcd.com/927/ ? > > On Mon, Feb 5, 2018 at 1:13 PM, Harendra Kumar > wrote: > >> According to hayoo there seem to be 7 different implementations of this >> same function. Yours is 8th and mine is 9th and other people may have more >> not uploaded or maybe the ones that hayoo is not able to find. Does that >> make a case for including this in some standard place? >> >> -harendra >> >> On 5 February 2018 at 12:22, Evan Laforge wrote: >> >>> I have my own list library with a bunch of things like this. I think >>> it's what most people do, and some upload them to hackage, e.g. >>> utility-ht or the split package, or data-ordlist. >>> >>> Specifically, I think rollingGroupBy is what I call splitWith: >>> >>> -- | Split @xs@ before places where @f@ matches. >>> -- >>> -- > split_with (==1) [1,2,1] >>> -- > --> [[], [1, 2], [1]] >>> split_with :: (a -> Bool) -> [a] -> NonNull [a] >>> -- ^ output is non-null, and the contents are also, except the first >>> one >>> >>> You can probably find something like this in 'split', or if not, that >>> might be a good place to contribute it. >>> >>> I have a bunch of grouping functions too, which I use all the time, so >>> if there's some kind of general list grouping package then maybe I >>> could put them there. >>> >>> On the other hand, this sort of thing is pretty individual, so it >>> doesn't seem so bad for each person to have their own local library. >>> That way you know it fits your style. Ultimately I think that's why >>> none of the split functions made it into Data.List, every person has a >>> slightly different idea of what it should be. >>> >>> On Sun, Feb 4, 2018 at 7:50 PM, Harendra Kumar >>> wrote: >>> > Hi, >>> > >>> > For a small problem, I was looking for a groupBy like function that >>> groups >>> > based on a predicate on successive elements but I could not find one. I >>> > wrote these little functions for that purpose: >>> > >>> > -- | Like span, but with a predicate that compares two successive >>> elements. >>> > The >>> > -- span ends when the two successive elements do not satisfy the >>> predicate. >>> > rollingSpan :: (a -> a -> Bool) -> [a] -> ([a], [a]) >>> > rollingSpan _ xs@[] = (xs, xs) >>> > rollingSpan _ xs@[_] = (xs, []) >>> > rollingSpan p (x1:xs@(x2:_)) >>> > | p x1 x2 = >>> > let (ys, zs) = rollingSpan p xs >>> > in (x1 : ys, zs) >>> > | otherwise = ([x1], xs) >>> > >>> > -- | Like 'groupBy' but with a predicate that compares two successive >>> > elements. >>> > -- A group ends when two successive elements do not satisfy the >>> predicate. >>> > rollingGroupBy :: (a -> a -> Bool) -> [a] -> [[a]] >>> > rollingGroupBy _ [] = [] >>> > rollingGroupBy cmp xs = >>> > let (ys, zs) = rollingSpan cmp xs >>> > in ys : rollingGroupBy cmp zs >>> > >>> > Are there any existing functions that serve this purpose or is there >>> any >>> > simpler way to achieve such functionality? If not, where is the right >>> place >>> > for these, if any. Can they be included in Data.List in base? >>> > >>> > Thanks, >>> > Harendra >>> > >>> > _______________________________________________ >>> > 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 >> >> > > > -- > 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 harendra.kumar at gmail.com Mon Feb 5 19:29:13 2018 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 6 Feb 2018 00:59:13 +0530 Subject: [Haskell-cafe] rolling span and groupBy for lists In-Reply-To: <87372fuuld.fsf@colimite.fr> References: <87tvuvs8h5.fsf@colimite.fr> <87372fuuld.fsf@colimite.fr> Message-ID: On 6 February 2018 at 00:33, Sergiu Ivanov wrote: > Thus quoth Harendra Kumar on Mon Feb 05 2018 at 18:30 (+0100): > > Yes, Hayoo seems to be giving better results, I found more variants > having > > the behavior I want, it seems this variant is quite popular but still not > > in any standard libraries. > > > > Interestingly the problem of too many choices and no standard one that > can > > be discovered applies to search engines as well. In this case there are > > only two choices but still it is of the same nature. I knew about hayoo > but > > forgot to use it in this case. How much time should one spend on finding > a > > trivial function before giving up and making the choice to write their > own? > > I wish there was a standard, quick, good quality way of discovering what > to > > use. It seems the Haskell ecosystem DNA encourages more and more > > fragmentation rather than consolidation. I think the community/leaders > > should acknowledge this problem and work on making things better in the > > short/long run. > > A Single Liberal Unified Registry of Haskell Packages (SLUPR), an effort > in this direction, has been recently announced: > Unfortunately, in my opinion, SLURP is taking things exactly in the opposite direction. I was talking about the problem of choice above and SLURP is giving even more choices and therefore encouraging more fragmentation. We should have just one good choice to stop wasting time and energy finding the best choice among millions available. Everyone should focus on making that one choice better rather spending energy in creating their own alternatives. This is where the Haskell ecosystem philosophy differs, it provides many choices in all aspects, it may be good in some cases but not always. SLURP is a technology solution which exactly fits in the same DNA. Technology can help us achieve the tasks that we set out to do but technology cannot motivate and influence us in what we choose to do and therefore ti cannot make the community focus on one goal - that requires real people leadership. If we do not focus on one goal, even with the best technology we may not succeed. Just my 2 cents. -harendra > > > > -harendra > > > > On 5 February 2018 at 22:02, Sergiu Ivanov wrote: > > > >> Hello Harendra, > >> > >> Thus quoth Harendra Kumar on Mon Feb 05 2018 at 16:43 (+0100): > >> > > >> > The irony is that theoretically you can find a Haskell package or > >> > implementation of whatever you can imagine but quite often it takes > more > >> > time to discover it than writing your own. > >> > >> Sometimes Hayoo! helps me out in such situations: > >> > >> http://hayoo.fh-wedel.de/?query=groupBy > >> > >> utility-ht shows up. > >> > >> -- > >> Sergiu > >> > > > -- > Sergiu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Feb 5 19:34:32 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 5 Feb 2018 14:34:32 -0500 Subject: [Haskell-cafe] rolling span and groupBy for lists In-Reply-To: References: <87tvuvs8h5.fsf@colimite.fr> <87372fuuld.fsf@colimite.fr> Message-ID: We have two groups of "leaders", with partially opposing goals. This is a disaster looking for an excuse to happen. On Mon, Feb 5, 2018 at 2:29 PM, Harendra Kumar wrote: > On 6 February 2018 at 00:33, Sergiu Ivanov wrote: > >> Thus quoth Harendra Kumar on Mon Feb 05 2018 at 18:30 (+0100): >> > Yes, Hayoo seems to be giving better results, I found more variants >> having >> > the behavior I want, it seems this variant is quite popular but still >> not >> > in any standard libraries. >> > >> > Interestingly the problem of too many choices and no standard one that >> can >> > be discovered applies to search engines as well. In this case there are >> > only two choices but still it is of the same nature. I knew about hayoo >> but >> > forgot to use it in this case. How much time should one spend on >> finding a >> > trivial function before giving up and making the choice to write their >> own? >> > I wish there was a standard, quick, good quality way of discovering >> what to >> > use. It seems the Haskell ecosystem DNA encourages more and more >> > fragmentation rather than consolidation. I think the community/leaders >> > should acknowledge this problem and work on making things better in the >> > short/long run. >> >> A Single Liberal Unified Registry of Haskell Packages (SLUPR), an effort >> in this direction, has been recently announced: >> > > Unfortunately, in my opinion, SLURP is taking things exactly in the > opposite direction. I was talking about the problem of choice above and > SLURP is giving even more choices and therefore encouraging more > fragmentation. We should have just one good choice to stop wasting time and > energy finding the best choice among millions available. Everyone should > focus on making that one choice better rather spending energy in creating > their own alternatives. This is where the Haskell ecosystem philosophy > differs, it provides many choices in all aspects, it may be good in some > cases but not always. SLURP is a technology solution which exactly fits in > the same DNA. Technology can help us achieve the tasks that we set out to > do but technology cannot motivate and influence us in what we choose to do > and therefore ti cannot make the community focus on one goal - that > requires real people leadership. If we do not focus on one goal, even with > the best technology we may not succeed. Just my 2 cents. > > -harendra > > > >> >> >> > -harendra >> > >> > On 5 February 2018 at 22:02, Sergiu Ivanov wrote: >> > >> >> Hello Harendra, >> >> >> >> Thus quoth Harendra Kumar on Mon Feb 05 2018 at 16:43 (+0100): >> >> > >> >> > The irony is that theoretically you can find a Haskell package or >> >> > implementation of whatever you can imagine but quite often it takes >> more >> >> > time to discover it than writing your own. >> >> >> >> Sometimes Hayoo! helps me out in such situations: >> >> >> >> http://hayoo.fh-wedel.de/?query=groupBy >> >> >> >> utility-ht shows up. >> >> >> >> -- >> >> Sergiu >> >> >> >> >> -- >> Sergiu >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- 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 michal.terepeta at gmail.com Mon Feb 5 19:53:24 2018 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Mon, 05 Feb 2018 19:53:24 +0000 Subject: [commit: ghc] master: Hoopl.Collections: change right folds to strict left folds (2974b2b) In-Reply-To: References: <20180203005629.80D0F3A5EE@ghc.haskell.org> Message-ID: On Mon, Feb 5, 2018 at 12:19 PM Simon Peyton Jones wrote: > Hi Michael > > Thanks for pushing forward with Hoopl and other back-end things. > > Did this patch elicit any performance gains? Or what brought it to your > attention? > I noticed this some time ago and just now got around to try it out. I was hoping for some improvements, sadly the differences (if any) were too small compared to noise. But it seemed like a nice change on its own, so I decided to send it out. > Do you have further plans for Hoopl and GHC's back end? > The biggest thing is probably: https://github.com/ghc-proposals/ghc-proposals/pull/74 Other than that, I haven't made any plans yet ;) There are a few tickets that I'd like to make some progress on. And I might try a few experiments looking for some compile-time improvements in the Hoopl/backend - I think currently nobody (including myself) is very keen on introducing new passes or making existing ones more powerful due to compile-time constraints. And then there are efforts by Moritz (LLVM backend using binary bitcode) and Kavon (LLVM changes to support CPS-style calls) that sound really interesting to me. (but they do require some more time to understand all the context/changes, so I'm not sure if or how much I'll be able to help) - Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue Feb 6 01:28:31 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 05 Feb 2018 20:28:31 -0500 Subject: The BlockArguments extension has been added to Cabal In-Reply-To: References: Message-ID: <87mv0mzz2d.fsf@smart-cactus.org> Akio Takano writes: > Dear GHC devs, > > The new `BlockArguments` extension has been added to the Cabal library. > > I'm sending out this notification because the Note [Adding a language > extension] in compiler/main/DynFlags.hs asks me to do so. > Thank you Akio! I will bump the Cabal submodule shortly. 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 Feb 6 10:29:28 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 6 Feb 2018 10:29:28 +0000 Subject: Can't typeset docs Message-ID: When I have BUILD_SPHINX_HTML = YES BUILD_SPHINX_PDF = YES I get this error in my build. Any ideas? I think Sphinx is up to date. Thanks Simon sh validate --fast --no-clean using THREADS=33 make: Entering directory '/5playpen/simonpj/HEAD-3/utils/checkUniques' ./check-uniques.py ../.. make: Leaving directory '/5playpen/simonpj/HEAD-3/utils/checkUniques' ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for 'phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all /usr/bin/sphinx-build -b html -d docs/users_guide/.doctrees-html -D latex_paper_size=letter docs/users_guide docs/users_guide/build-html/users_guide /usr/bin/sphinx-build -b latex -d docs/users_guide/.doctrees-pdf -D latex_paper_size=letter docs/users_guide docs/users_guide/build-pdf/users_guide /usr/bin/sphinx-build -b man -d docs/users_guide/.doctrees-man docs/users_guide docs/users_guide/build-man Running Sphinx v1.3.6 making output directory... Running Sphinx v1.3.6 Exception occurred: making output directory... Exception occurred: Running Sphinx v1.3.6 making output directory... Exception occurred: File "conf.py", line 13, in from ghc_config import extlinks, version ImportError: No module named ghc_config File "conf.py", line 13, in from ghc_config import extlinks, version ImportError: No module named ghc_config File "conf.py", line 13, in from ghc_config import extlinks, version ImportError: No module named ghc_config The full traceback has been saved in /tmp/sphinx-err-d_zVKs.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at . Thanks! The full traceback has been saved in /tmp/sphinx-err-hbXcSK.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at . Thanks! The full traceback has been saved in /tmp/sphinx-err-lmyy8H.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at . Thanks! docs/users_guide/ghc.mk:28: recipe for target 'docs/users_guide/build-man/ghc.1' failed make[1]: *** [docs/users_guide/build-man/ghc.1] Error 1 make[1]: *** Waiting for unfinished jobs.... docs/users_guide/ghc.mk:16: recipe for target 'docs/users_guide/users_guide.pdf' failed make[1]: *** [docs/users_guide/users_guide.pdf] Error 1 docs/users_guide/ghc.mk:16: recipe for target 'docs/users_guide/build-html/users_guide/index.html' failed make[1]: *** [docs/users_guide/build-html/users_guide/index.html] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 simonpj at cam-05-unx:~/5builds/HEAD-3$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Tue Feb 6 12:58:34 2018 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Tue, 6 Feb 2018 21:58:34 +0900 Subject: The BlockArguments extension has been added to Cabal In-Reply-To: References: Message-ID: Akio, thank you for telling me as well. I will also add `NumericUnderscores` extension to the Cabal library this weekend. Regards, Takenobu 2018-02-05 16:06 GMT+09:00 Akio Takano : > Dear GHC devs, > > The new `BlockArguments` extension has been added to the Cabal library. > > I'm sending out this notification because the Note [Adding a language > extension] in compiler/main/DynFlags.hs asks me to do so. > > Regards, > Takano Akio > _______________________________________________ > 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 well-typed.com Tue Feb 6 16:43:10 2018 From: ben at well-typed.com (Ben Gamari) Date: Tue, 06 Feb 2018 11:43:10 -0500 Subject: [ANNOUNCE] GHC 8.4.1-alpha3 available Message-ID: <87d11iyspz.fsf@smart-cactus.org> The GHC development team is pleased to announce the third and likely last alpha release leading up to GHC 8.4.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-alpha3 Due to user demand we now offer a binary distribution for 64-bit Fedora 27, which links against ncurses6. This is in contrast to the Debian 8 distribution, which links against ncurses5. Users of newer distributions (Fedora 27, Debian Sid) should use this new Fedora 27 distribution. Also due to user demand we have reintroduced compatibility with GCC 4.4, which earlier alphas had dropped due to #14244. Note that this release is still affected by #14675, wherein the compiler will segmentation fault when built with some Ubuntu toolchains. We are actively working to identify the cause and hope that this will be resolved before the final release. === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes into users' hands and more quickly identify potential issues. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-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 ben at well-typed.com Tue Feb 6 16:46:16 2018 From: ben at well-typed.com (Ben Gamari) Date: Tue, 06 Feb 2018 11:46:16 -0500 Subject: Can't typeset docs In-Reply-To: References: Message-ID: <878tc6yskq.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > When I have > > BUILD_SPHINX_HTML = YES > > BUILD_SPHINX_PDF = YES > I get this error in my build. Any ideas? I think Sphinx is up to date. > Thanks > Simon > I suspect the cause here is the --no-clean, which doesn't run ./boot and ./configure. The latter generates docs/users_guide/ghc_config.py, which appears to be missing. Is the problem reproducible with a fresh validate? 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 david.feuer at gmail.com Wed Feb 7 01:11:25 2018 From: david.feuer at gmail.com (David Feuer) Date: Tue, 6 Feb 2018 20:11:25 -0500 Subject: Strict unlifted types Message-ID: Sometimes there's an awkward expressive tension between saying that a type is *unboxed* and saying that it is *strict* in a field. For example, I can write data SMaybe a = SNothing | SJust !a or I can write type Maybe# a = (# (# #) | a #) but there doesn't seem to be a way to simultaneously get both unboxed and strict. I'm wondering if it might make sense to add a type to serve the purpose Strict# :: Type -> TYPE 'UnliftedRep mkStrict# :: a -> Strict# a -- force the argument getStrict# :: Strict# a -> a -- do nothing, but know the result is in WHNF Then one could write, for example, type SMaybe# a = (# (# #) | Strict# a #) at which point SMaybe is *precisely* isomorphic to the alternative representation data SMaybe' a = SMaybe' (SMaybe# a) David From simonpj at microsoft.com Wed Feb 7 09:08:10 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 7 Feb 2018 09:08:10 +0000 Subject: Strict unlifted types In-Reply-To: References: Message-ID: Sounds similar to https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | David Feuer | Sent: 07 February 2018 01:11 | To: ghc-devs | Subject: Strict unlifted types | | Sometimes there's an awkward expressive tension between saying that a | type is *unboxed* and saying that it is *strict* in a field. For | example, I can write | | data SMaybe a = SNothing | SJust !a | | or I can write | | type Maybe# a = (# (# #) | a #) | | but there doesn't seem to be a way to simultaneously get both unboxed | and strict. I'm wondering if it might make sense to add a type to | serve the purpose | | Strict# :: Type -> TYPE 'UnliftedRep | | mkStrict# :: a -> Strict# a -- force the argument getStrict# :: | Strict# a -> a -- do nothing, but know the result is in WHNF | | Then one could write, for example, | | type SMaybe# a = (# (# #) | Strict# a #) | | at which point SMaybe is *precisely* isomorphic to the alternative | representation | | data SMaybe' a = SMaybe' (SMaybe# a) | | 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%7Cdf3667262c11430fef8008d5 | 6dc7c3e7%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C6365356271225789 | 33%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI | 6Ik1haWwifQ%3D%3D%7C- | 1&sdata=x736pxmxWrkybgV6xXLjIT9EFnKibMJuiEyJpj1SfSw%3D&reserved=0 From simonpj at microsoft.com Wed Feb 7 09:16:59 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 7 Feb 2018 09:16:59 +0000 Subject: Can't typeset docs In-Reply-To: <878tc6yskq.fsf@smart-cactus.org> References: <878tc6yskq.fsf@smart-cactus.org> Message-ID: | > When I have | > | > BUILD_SPHINX_HTML = YES | > | > BUILD_SPHINX_PDF = YES | > I get this error in my build. Any ideas? I think Sphinx is up to | date. | > Thanks | > Simon | > | I suspect the cause here is the --no-clean, which doesn't run ./boot | and ./configure. The latter generates docs/users_guide/ghc_config.py, | which appears to be missing. Is the problem reproducible with a fresh | validate? Thanks Ben. I think you are right -- sorry about that. I didn't know that you need to start from clean of you change those settings. But a fresh validate still fails, just differently. Tail of the log is below. There seem be two suspicious lines: Package cmap Warning: pdftex not detected - exiting. and later (/usr/share/texlive/texmf-dist/doc/support/pedigree-perl/examples/english.cfg ! You can't use `macro parameter character #' in vertical mode. l.1 # An example configuration file for pedigree program No pages of output. Full log below Oh, and I do have pdftex: simonpj at cam-05-unx:~/5builds/HEAD-3$ pdftex --version pdfTeX 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) kpathsea version 6.2.1 Copyright 2015 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Compiled with libpng 1.6.17; using libpng 1.6.17 Compiled with zlib 1.2.8; using zlib 1.2.8 Compiled with poppler version 0.41.0 simonpj at cam-05-unx:~/5builds/HEAD-3$ Simon flow.thr_l_dyn_o rts/dist/build/sm/MBlock.thr_l_dyn_o rts/dist/build/sm/Scav.thr_l_dyn_o rts/dist/build/sm/CNF.thr_l_dyn_o rts/dist/build/sm/Compact.thr_l_dyn_o rts/dist/build/sm/GCAux.thr_l_dyn_o rts/dist/build/sm/Sweep.thr_l_dyn_o rts/dist/build/sm/GCUtils.thr_l_dyn_o rts/dist/build/sm/BlockAlloc.thr_l_dyn_o rts/dist/build/sm/Evac_thr.thr_l_dyn_o rts/dist/build/sm/MarkWeak.thr_l_dyn_o rts/dist/build/sm/GC.thr_l_dyn_o rts/dist/build/sm/Sanity.thr_l_dyn_o rts/dist/build/sm/Evac.thr_l_dyn_o rts/dist/build/sm/Storage.thr_l_dyn_o rts/dist/build/sm/Scav_thr.thr_l_dyn_o rts/dist/build/eventlog/EventLogWriter.thr_l_dyn_o rts/dist/build/eventlog/EventLog.thr_l_dyn_o rts/dist/build/linker/elf_reloc_aarch64.thr_l_dyn_o rts/dist/build/linker/MachO.thr_l_dyn_o rts/dist/build/linker/PEi386.thr_l_dyn_o rts/dist/build/linker/elf_plt.thr_l_dyn_o rts/dist/build/linker/elf_reloc.thr_l_dyn_o rts/dist/build/linker/elf_plt_aarch64.thr_l_dyn_o rts/dist/build/linker/M32Alloc.thr_l_dyn_o rts/dist/build/linker/Elf.thr_l_dyn_o rts/dist/build/linker/CacheFlush.thr_l_dyn_o rts/dist/build/linker/elf_got.thr_l_dyn_o rts/dist/build/linker/SymbolExtras.thr_l_dyn_o rts/dist/build/linker/elf_plt_arm.thr_l_dyn_o rts/dist/build/linker/LoadArchive.thr_l_dyn_o rts/dist/build/linker/elf_util.thr_l_dyn_o rts/dist/build/posix/OSMem.thr_l_dyn_o rts/dist/build/posix/GetTime.thr_l_dyn_o rts/dist/build/posix/OSThreads.thr_l_dyn_o rts/dist/build/posix/Itimer.thr_l_dyn_o rts/dist/build/posix/TTY.thr_l_dyn_o rts/dist/build/posix/Signals.thr_l_dyn_o rts/dist/build/posix/Select.thr_l_dyn_o rts/dist/build/posix/GetEnv.thr_l_dyn_o rts/dist/build/StgStartup.thr_l_dyn_o rts/dist/build/Updates.thr_l_dyn_o rts/dist/build/Exception.thr_l_dyn_o rts/dist/build/StgMiscClosures.thr_l_dyn_o rts/dist/build/Apply.thr_l_dyn_o rts/dist/build/Compact.thr_l_dyn_o rts/dist/build/StgStdThunks.thr_l_dyn_o rts/dist/build/HeapStackCheck.thr_l_dyn_o rts/dist/build/PrimOps.thr_l_dyn_o rts/dist/build/AutoApply.thr_l_dyn_o -fPIC -dynamic -optc-DTHREADED_RTS -eventlog -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -o rts/dist/build/libHSrts_thr_l-ghc8.5.20180207.so reading sources... [ 28%] ffi-chap "rm" -f rts/dist/build/libHSrts_debug.a reading sources... [ 28%] ffi-chap echo rts/dist/build/ProfHeap.debug_o rts/dist/build/TopHandler.debug_o rts/dist/build/Stats.debug_o rts/dist/build/Arena.debug_o rts/dist/build/Stable.debug_o rts/dist/build/Linker.debug_o rts/dist/build/RtsFlags.debug_o rts/dist/build/Sparks.debug_o rts/dist/build/Profiling.debug_o rts/dist/build/RetainerSet.debug_o rts/dist/build/RtsStartup.debug_o rts/dist/build/FileLock.debug_o rts/dist/build/StgPrimFloat.debug_o rts/dist/build/CheckUnload.debug_o rts/dist/build/StaticPtrTable.debug_o rts/dist/build/WSDeque.debug_o rts/dist/build/Disassembler.debug_o rts/dist/build/ProfilerReport.debug_o rts/dist/build/RtsDllMain.debug_o rts/dist/build/Schedule.debug_o rts/dist/build/Adjustor.debug_o rts/dist/build/Globals.debug_o rts/dist/build/Capability.debug_o rts/dist/build/Threads.debug_o rts/dist/build/xxhash.debug_o rts/dist/build/RtsUtils.debug_o rts/dist/build/Messages.debug_o rts/dist/build/Interpreter.debug_o rts/dist/build/Hpc.debug_o rts/dist/build/Libdw.debug_o rts/dist/build/RetainerProfile.debug_o rts/dist/build/ClosureFlags.debug_o rts/dist/build/LdvProfile.debug_o rts/dist/build/StgCRun.debug_o rts/dist/build/Task.debug_o rts/dist/build/ProfilerReportJson.debug_o rts/dist/build/Weak.debug_o rts/dist/build/Trace.debug_o rts/dist/build/Hash.debug_o rts/dist/build/RtsMessages.debug_o rts/dist/build/RaiseAsync.debug_o rts/dist/build/RtsSymbolInfo.debug_o rts/dist/build/Timer.debug_o rts/dist/build/RtsAPI.debug_o rts/dist/build/HsFFI.debug_o rts/dist/build/OldARMAtomic.debug_o rts/dist/build/ThreadLabels.debug_o rts/dist/build/Proftimer.debug_o rts/dist/build/RtsSymbols.debug_o rts/dist/build/PathUtils.debug_o rts/dist/build/RtsMain.debug_o rts/dist/build/Inlines.debug_o rts/dist/build/Ticky.debug_o rts/dist/build/Pool.debug_o rts/dist/build/LibdwPool.debug_o rts/dist/build/ThreadPaused.debug_o rts/dist/build/Printer.debug_o rts/dist/build/STM.debug_o rts/dist/build/hooks/OutOfHeap.debug_o rts/dist/build/hooks/MallocFail.debug_o rts/dist/build/hooks/FlagDefaults.debug_o rts/dist/build/hooks/OnExit.debug_o rts/dist/build/hooks/LongGCSync.debug_o rts/dist/build/hooks/StackOverflow.debug_o rts/dist/build/sm/MBlock.debug_o rts/dist/build/sm/Scav.debug_o rts/dist/build/sm/CNF.debug_o rts/dist/build/sm/Compact.debug_o rts/dist/build/sm/GCAux.debug_o rts/dist/build/sm/Sweep.debug_o rts/dist/build/sm/GCUtils.debug_o rts/dist/build/sm/BlockAlloc.debug_o rts/dist/build/sm/Evac_thr.debug_o rts/dist/build/sm/MarkWeak.debug_o rts/dist/build/sm/GC.debug_o rts/dist/build/sm/Sanity.debug_o rts/dist/build/sm/Evac.debug_o rts/dist/build/sm/Storage.debug_o rts/dist/build/sm/Scav_thr.debug_o rts/dist/build/eventlog/EventLogWriter.debug_o rts/dist/build/eventlog/EventLog.debug_o rts/dist/build/linker/elf_reloc_aarch64.debug_o rts/dist/build/linker/MachO.debug_o rts/dist/build/linker/PEi386.debug_o rts/dist/build/linker/elf_plt.debug_o rts/dist/build/linker/elf_reloc.debug_o rts/dist/build/linker/elf_plt_aarch64.debug_o rts/dist/build/linker/M32Alloc.debug_o rts/dist/build/linker/Elf.debug_o rts/dist/build/linker/CacheFlush.debug_o rts/dist/build/linker/elf_got.debug_o rts/dist/build/linker/SymbolExtras.debug_o rts/dist/build/linker/elf_plt_arm.debug_o rts/dist/build/linker/LoadArchive.debug_o rts/dist/build/linker/elf_util.debug_o rts/dist/build/posix/OSMem.debug_o rts/dist/build/posix/GetTime.debug_o rts/dist/build/posix/OSThreads.debug_o rts/dist/build/posix/Itimer.debug_o rts/dist/build/posix/TTY.debug_o rts/dist/build/posix/Signals.debug_o rts/dist/build/posix/Select.debug_o rts/dist/build/posix/GetEnv.debug_o rts/dist/build/StgStartup.debug_o rts/dist/build/Updates.debug_o rts/dist/build/Exception.debug_o rts/dist/build/StgMiscClosures.debug_o rts/dist/build/Apply.debug_o rts/dist/build/Compact.debug_o rts/dist/build/StgStdThunks.debug_o rts/dist/build/HeapStackCheck.debug_o rts/dist/build/PrimOps.debug_o rts/dist/build/AutoApply.debug_o | "xargs" "ar" q rts/dist/build/libHSrts_debug.a ar: creating rts/dist/build/libHSrts_debug.a reading sources... [ 31%] flags reading sources... [ 31%] flags reading sources... [ 31%] flags reading sources... [ 34%] ghc reading sources... [ 34%] ghc reading sources... [ 34%] ghc reading sources... [ 36%] ghci reading sources... [ 36%] ghci reading sources... [ 36%] ghci reading sources... [ 39%] glasgow_exts reading sources... [ 39%] glasgow_exts reading sources... [ 39%] glasgow_exts reading sources... [ 42%] gone_wrong reading sources... [ 44%] index reading sources... [ 42%] gone_wrong reading sources... [ 47%] intro reading sources... [ 42%] gone_wrong reading sources... [ 44%] index reading sources... [ 44%] index reading sources... [ 47%] intro reading sources... [ 50%] lang reading sources... [ 47%] intro reading sources... [ 52%] license reading sources... [ 55%] packages reading sources... [ 50%] lang reading sources... [ 52%] license reading sources... [ 50%] lang reading sources... [ 55%] packages reading sources... [ 52%] license reading sources... [ 55%] packages reading sources... [ 57%] parallel reading sources... [ 60%] phases reading sources... [ 57%] parallel reading sources... [ 57%] parallel reading sources... [ 60%] phases reading sources... [ 60%] phases reading sources... [ 63%] profiling reading sources... [ 63%] profiling reading sources... [ 63%] profiling reading sources... [ 65%] runghc reading sources... [ 68%] runtime_control reading sources... [ 65%] runghc reading sources... [ 65%] runghc reading sources... [ 68%] runtime_control reading sources... [ 68%] runtime_control reading sources... [ 71%] safe_haskell reading sources... [ 71%] safe_haskell reading sources... [ 71%] safe_haskell reading sources... [ 73%] separate_compilation reading sources... [ 73%] separate_compilation reading sources... [ 73%] separate_compilation reading sources... [ 76%] shared_libs reading sources... [ 76%] shared_libs reading sources... [ 78%] sooner reading sources... [ 76%] shared_libs reading sources... [ 78%] sooner reading sources... [ 78%] sooner reading sources... [ 81%] usage reading sources... [ 84%] using reading sources... [ 81%] usage reading sources... [ 84%] using reading sources... [ 81%] usage reading sources... [ 84%] using reading sources... [ 86%] using-concurrent reading sources... [ 89%] using-optimisation reading sources... [ 86%] using-concurrent reading sources... [ 86%] using-concurrent reading sources... [ 89%] using-optimisation reading sources... [ 89%] using-optimisation reading sources... [ 92%] using-warnings reading sources... [ 92%] using-warnings reading sources... [ 92%] using-warnings reading sources... [ 94%] utils reading sources... [ 94%] utils reading sources... [ 97%] what_glasgow_exts_does reading sources... [ 94%] utils reading sources... [100%] win32-dlls reading sources... [ 97%] what_glasgow_exts_does reading sources... [100%] win32-dlls reading sources... [ 97%] what_glasgow_exts_does /5playpen/simonpj/HEAD-3/docs/users_guide/using-optimisation.rst:: ERROR: Anonymous hyperlink mismatch: 1 references but 0 targets. See "backrefs" attribute for IDs. looking for now-outdated files... reading sources... [100%] win32-dlls /5playpen/simonpj/HEAD-3/docs/users_guide/using-optimisation.rst:: ERROR: Anonymous hyperlink mismatch: 1 references but 0 targets. See "backrefs" attribute for IDs. looking for now-outdated files... /5playpen/simonpj/HEAD-3/docs/users_guide/using-optimisation.rst:: ERROR: Anonymous hyperlink mismatch: 1 references but 0 targets. See "backrefs" attribute for IDs. looking for now-outdated files... none found pickling environment... none found pickling environment... none found pickling environment... done checking consistency... /5playpen/simonpj/HEAD-3/docs/users_guide/8.6.1-notes.rst:: WARNING: document isn't included in any toctree /5playpen/simonpj/HEAD-3/docs/users_guide/what_glasgow_exts_does.rst:: WARNING: document isn't included in any toctree done preparing documents... done writing output... [ 2%] 8.2.1-notes done checking consistency... /5playpen/simonpj/HEAD-3/docs/users_guide/8.6.1-notes.rst:: WARNING: document isn't included in any toctree /5playpen/simonpj/HEAD-3/docs/users_guide/what_glasgow_exts_does.rst:: WARNING: document isn't included in any toctree done done checking consistency... /5playpen/simonpj/HEAD-3/docs/users_guide/8.6.1-notes.rst:: WARNING: document isn't included in any toctree /5playpen/simonpj/HEAD-3/docs/users_guide/what_glasgow_exts_does.rst:: WARNING: document isn't included in any toctree done writing... ghc.1 { processing users_guide.tex... index license intro } 8.2.1-notes 8.4.1-notes ghci writing output... [ 5%] 8.4.1-notes runghc usage using using-warnings writing output... [ 7%] 8.6.1-notes using-optimisation writing output... [ 10%] bugs build succeeded, 3 warnings. writing output... [ 13%] codegens using-concurrent flags writing output... [ 15%] debug-info runtime_control separate_compilation writing output... [ 18%] debugging packages writing output... [ 21%] editing-guide codegens writing output... [ 23%] eventlog-formats phases writing output... [ 26%] extending_ghc shared_libs debugging profiling writing output... [ 28%] ffi-chap sooner writing output... [ 31%] flags lang glasgow_exts writing output... [ 34%] ghc parallel safe_haskell ffi-chap extending_ghc gone_wrong debug-info writing output... [ 36%] ghci utils win32-dlls bugs eventlog-formats editing-guide resolving references... writing output... [ 39%] glasgow_exts writing... /5playpen/simonpj/HEAD-3/docs/users_guide/8.2.1-notes.rst:: WARNING: unusable reference target found: ../libraries/ghc-compact-0.1.0.0/GHC-Compact.html /5playpen/simonpj/HEAD-3/docs/users_guide/ghci.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Exception.html /5playpen/simonpj/HEAD-3/docs/users_guide/using-concurrent.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Concurrent.html /5playpen/simonpj/HEAD-3/docs/users_guide/using-concurrent.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Concurrent.html#v:setNumCapabilities /5playpen/simonpj/HEAD-3/docs/users_guide/using-concurrent.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Concurrent.html#v:forkOn /5playpen/simonpj/HEAD-3/docs/users_guide/runtime_control.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-Conc.html#v:enableAllocationLimit /5playpen/simonpj/HEAD-3/docs/users_guide/runtime_control.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-Conc.html#v:par /5playpen/simonpj/HEAD-3/docs/users_guide/runtime_control.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-Stats.html /5playpen/simonpj/HEAD-3/docs/users_guide/packages.rst:: WARNING: unusable reference target found: ../libraries/index.html /5playpen/simonpj/HEAD-3/docs/users_guide/packages.rst:: WARNING: unusable reference target found: ../libraries/Cabal-2.1.0.0/Distribution-Simple.html /5playpen/simonpj/HEAD-3/docs/users_guide/packages.rst:: WARNING: unusable reference target found: ../libraries/Cabal-2.1.0.0/Distribution-InstalledPackageInfo.html#t:InstalledPackageInfo /5playpen/simonpj/HEAD-3/docs/users_guide/packages.rst:: WARNING: unusable reference target found: ../libraries/Cabal-2.1.0.0/Distribution-License.html#t:License /5playpen/simonpj/HEAD-3/docs/users_guide/profiling.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Debug-Trace.html#v:traceShow /5playpen/simonpj/HEAD-3/docs/users_guide/sooner.rst:: WARNING: unusable reference target found: ../libraries/array- at LIBRARY_array_VERSION@/Data-Array-Unboxed.html /5playpen/simonpj/HEAD-3/docs/users_guide/sooner.rst:: WARNING: unusable reference target found: ../libraries/array- at LIBRARY_array_VERSION@/Data-Array.html /5playpen/simonpj/HEAD-3/docs/users_guide/sooner.rst:: WARNING: unusable reference target found: ../libraries/ghc-compact-0.1.0.0/GHC-Compact.html /5playpen/simonpj/HEAD-3/docs/users_guide/sooner.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Prelude.html#t:Read /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/index.html /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/ghc-prim-0.5.2.0/detailed online documentation /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Monad-Zip.html /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-Records.html writing output... [ 42%] gone_wrong /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-OverloadedLabels.html writing output... [ 44%] index writing output... [ 47%] intro writing output... [ 50%] lang /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Data-Coerce.html writing output... [ 52%] license writing output... [ 55%] packages /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-TypeLits.html /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/template-haskell- at LIBRARY_template_haskell_VERSION@/Haddock reference documentation /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Arrow.html /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Arrow.html /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Arrow.html /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Arrow.html writing output... [ 57%] parallel /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control.html#t:Exception /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-StaticPtr.html#v:unsafeLookupStaticPtr /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-StaticPtr.html#v:deRefStaticPtr writing output... [ 60%] phases /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-StaticPtr.html#t:IsStatic /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/Cabal-2.1.0.0/Language-Haskell-Extension.html writing output... [ 63%] profiling /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-Exts.html#v:inline /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-Exts.html#v:lazy /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-Exts.html#v:oneShot /5playpen/simonpj/HEAD-3/docs/users_guide/glasgow_exts.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-Generics.html /5playpen/simonpj/HEAD-3/docs/users_guide/parallel.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Concurrent.html /5playpen/simonpj/HEAD-3/docs/users_guide/ffi-chap.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Foreign.html writing output... [ 65%] runghc /5playpen/simonpj/HEAD-3/docs/users_guide/ffi-chap.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Concurrent.html writing output... [ 68%] runtime_control /5playpen/simonpj/HEAD-3/docs/users_guide/extending_ghc.rst:: WARNING: unusable reference target found: ../libraries/template-haskell- at LIBRARY_template_haskell_VERSION@/Language-Haskell-TH-Syntax.html#v:addCorePlugin /5playpen/simonpj/HEAD-3/docs/users_guide/debug-info.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-ExecutionStack.html /5playpen/simonpj/HEAD-3/docs/users_guide/win32-dlls.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-ConsoleHandler.html writing output... [ 71%] safe_haskell done copying images... images/prof_scc.pdf copying TeX support files... done build succeeded, 47 warnings. writing output... [ 73%] separate_compilation writing output... [ 76%] shared_libs cd docs/users_guide/build-pdf/users_guide ; xelatex -halt-on-error users_guide.tex This is XeTeX, Version 3.14159265-2.6-0.99992 (TeX Live 2015/Debian) (preloaded format=xelatex) restricted \write18 enabled. writing output... [ 78%] sooner writing output... [ 81%] usage writing output... [ 84%] using entering extended mode (./users_guide.tex LaTeX2e <2016/02/01> Babel <3.9q> and hyphenation patterns for 81 language(s) loaded. (./sphinxmanual.cls Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual) writing output... [ 86%] using-concurrent writing output... [ 89%] using-optimisation writing output... [ 92%] using-warnings writing output... [ 94%] utils writing output... [ 97%] what_glasgow_exts_does writing output... [100%] win32-dlls generating indices... genindex writing additional pages... search opensearch copying images... [100%] images/prof_scc.svg copying static files... done copying extra files... done dumping search index in English (code: en) ... done dumping object inventory... done build succeeded, 3 warnings. (/usr/share/texlive/texmf-dist/tex/latex/base/report.cls Document Class: report 2014/09/29 v1.4h Standard LaTeX document class (/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))) (/usr/share/texlive/texmf-dist/tex/latex/cmap/cmap.sty Package cmap Warning: pdftex not detected - exiting. ) (/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty (/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.def)) (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amsfonts.sty) (/usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty ************************************* * Local config file bblopts.cfg used * (/usr/share/texlive/texmf-dist/doc/latex/arabi/bblopts.cfg) (/usr/share/texlive/texmf-dist/tex/generic/babel-english/english.ldf (/usr/share/texlive/texmf-dist/tex/generic/babel/babel.def (/usr/share/texlive/texmf-dist/tex/generic/babel/xebabel.def)) ************************************* * Local config file english.cfg used * (/usr/share/texlive/texmf-dist/doc/support/pedigree-perl/examples/english.cfg ! You can't use `macro parameter character #' in vertical mode. l.1 # An example configuration file for pedigree program No pages of output. Transcript written on users_guide.log. docs/users_guide/ghc.mk:16: recipe for target 'docs/users_guide/users_guide.pdf' failed make[1]: *** [docs/users_guide/users_guide.pdf] Error 1 make[1]: *** Waiting for unfinished jobs.... Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 simonpj at cam-05-unx:~/5builds/HEAD-3$ | -----Original Message----- | From: Ben Gamari [mailto:ben at well-typed.com] | Sent: 06 February 2018 16:46 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: Can't typeset docs | | Simon Peyton Jones via ghc-devs writes: | | > When I have | > | > BUILD_SPHINX_HTML = YES | > | > BUILD_SPHINX_PDF = YES | > I get this error in my build. Any ideas? I think Sphinx is up to | date. | > Thanks | > Simon | > | I suspect the cause here is the --no-clean, which doesn't run ./boot | and ./configure. The latter generates docs/users_guide/ghc_config.py, | which appears to be missing. Is the problem reproducible with a fresh | validate? | | Cheers, | | - Ben From simonpj at microsoft.com Wed Feb 7 09:54:00 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 7 Feb 2018 09:54:00 +0000 Subject: package01e failure Message-ID: I'm getting this test failure, presumably because of a version bump in containers. I think this is a clean build from scratch. Could someone have forgotten to update a test file? Simon =====> package01e(normal) 1 of 1 [0, 0, 0] cd "./package01e.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -c package01e.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -hide-all-packages -XNoImplicitPrelude -package "containers (Data.Map as Map, Data.Set)" Actual stderr output differs from expected: diff -uw "./package01e.run/package01e.stderr.normalised" "./package01e.run/package01e.comp.stderr.normalised" --- ./package01e.run/package01e.stderr.normalised 2018-02-07 09:52:44.562487065 +0000 +++ ./package01e.run/package01e.comp.stderr.normalised 2018-02-07 09:52:44.562487065 +0000 @@ -2,9 +2,11 @@ package01e.hs:2:1: Could not find module 'Data.Map' It is a member of the hidden package 'containers-0.5.11.0'. + It is a member of the hidden package 'containers-0.5.10.2'. Use -v to see a list of the files searched for. package01e.hs:3:1: Could not find module 'Data.IntMap' It is a member of the hidden package 'containers-0.5.11.0'. + It is a member of the hidden package 'containers-0.5.10.2'. Use -v to see a list of the files searched for. *** unexpected failure for package01e(normal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at well-typed.com Wed Feb 7 09:59:05 2018 From: david at well-typed.com (David Feuer) Date: Wed, 07 Feb 2018 04:59:05 -0500 Subject: package01e failure In-Reply-To: Message-ID: <20180207092547.C6C12BCDD4@haskell.org> The Phabricator differential validated successfully, so that's somewhat surprising. David FeuerWell-Typed, LLP -------- Original message --------From: Simon Peyton Jones via ghc-devs Date: 2/7/18 4:54 AM (GMT-05:00) To: ghc-devs Subject: package01e failure I'm getting this test failure, presumably because of a version bump in containers.  I think this is a clean build from scratch. Could someone have forgotten to update a test file? Simon =====> package01e(normal) 1 of 1 [0, 0, 0] cd "./package01e.run" &&  "/5playpen/simonpj/HEAD-5/inplace/test   spaces/ghc-stage2" -c package01e.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output  -hide-all-packages -XNoImplicitPrelude -package "containers (Data.Map as Map, Data.Set)" Actual stderr output differs from expected: diff -uw "./package01e.run/package01e.stderr.normalised" "./package01e.run/package01e.comp.stderr.normalised" --- ./package01e.run/package01e.stderr.normalised    2018-02-07 09:52:44.562487065 +0000 +++ ./package01e.run/package01e.comp.stderr.normalised      2018-02-07 09:52:44.562487065 +0000 @@ -2,9 +2,11 @@ package01e.hs:2:1:      Could not find module 'Data.Map'      It is a member of the hidden package 'containers-0.5.11.0'. +    It is a member of the hidden package 'containers-0.5.10.2'.      Use -v to see a list of the files searched for. package01e.hs:3:1:      Could not find module 'Data.IntMap'      It is a member of the hidden package 'containers-0.5.11.0'. +    It is a member of the hidden package 'containers-0.5.10.2'.      Use -v to see a list of the files searched for. *** unexpected failure for package01e(normal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Feb 7 23:13:50 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 7 Feb 2018 23:13:50 +0000 Subject: Windows build broken -- help! Message-ID: Aargh. Windows build is broken again. Log below. Help! Simon "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-DWINVER=0x06000100 -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgPrimFloat.c -o rts/dist/build/StgPrimFloat.o rts\Schedule.c:274:14: error: error: unknown conversion type character 'l' in format [-Werror=format=] barf("sched_state: %" FMT_Word, sched_state); ^~~~~~~~~~~~~~~~ | 274 | barf("sched_state: %" FMT_Word, sched_state); | ^ In file included from C:/code/HEAD-1/inplace/mingw/x86_64-w64-mingw32/include/stdio.h:1036:0, from includes/rts/Flags.h:16, from includes/Rts.h:191, from rts\Schedule.c:11:0: error: C:/code/HEAD-1/inplace/mingw/x86_64-w64-mingw32/include/_mingw_print_pop.h:86:18: note: format string is defined here #define PRIu64 "llu" ^ rts\Schedule.c:274:14: error: error: too many arguments for format [-Werror=format-extra-args] barf("sched_state: %" FMT_Word, sched_state); ^~~~~~~~~~~~~~~~ | 274 | barf("sched_state: %" FMT_Word, sched_state); | ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-DWINVER=0x06000100 -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/Profiling.c -o rts/dist/build/Profiling.o make[1]: *** [rts/ghc.mk:295: rts/dist/build/Schedule.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:127: all] Error 2 /c/code/HEAD-1$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Feb 7 23:18:22 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 7 Feb 2018 23:18:22 +0000 Subject: Windows build broken -- help! In-Reply-To: References: Message-ID: PS Presumably it's these commits commit 00f1a4ab80b201ce15c509126f89c5a108786f32 Author: Douglas Wilson Date: Tue Feb 6 17:27:32 2018 -0500 rts: fix some barf format specifiers. Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4390 commit 4d1c3b72ec27c8e51fb40809bba3ce35246a2966 Author: Ben Gamari Date: Tue Feb 6 13:27:35 2018 -0500 rts: Add format attribute to barf Test Plan: Validate Reviewers: erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4374 From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon Peyton Jones via ghc-devs Sent: 07 February 2018 23:14 To: ghc-devs ; Phyx Subject: Windows build broken -- help! Aargh. Windows build is broken again. Log below. Help! Simon "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-DWINVER=0x06000100 -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgPrimFloat.c -o rts/dist/build/StgPrimFloat.o rts\Schedule.c:274:14: error: error: unknown conversion type character 'l' in format [-Werror=format=] barf("sched_state: %" FMT_Word, sched_state); ^~~~~~~~~~~~~~~~ | 274 | barf("sched_state: %" FMT_Word, sched_state); | ^ In file included from C:/code/HEAD-1/inplace/mingw/x86_64-w64-mingw32/include/stdio.h:1036:0, from includes/rts/Flags.h:16, from includes/Rts.h:191, from rts\Schedule.c:11:0: error: C:/code/HEAD-1/inplace/mingw/x86_64-w64-mingw32/include/_mingw_print_pop.h:86:18: note: format string is defined here #define PRIu64 "llu" ^ rts\Schedule.c:274:14: error: error: too many arguments for format [-Werror=format-extra-args] barf("sched_state: %" FMT_Word, sched_state); ^~~~~~~~~~~~~~~~ | 274 | barf("sched_state: %" FMT_Word, sched_state); | ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-DWINVER=0x06000100 -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/Profiling.c -o rts/dist/build/Profiling.o make[1]: *** [rts/ghc.mk:295: rts/dist/build/Schedule.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:127: all] Error 2 /c/code/HEAD-1$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.wilson at gmail.com Wed Feb 7 23:32:17 2018 From: douglas.wilson at gmail.com (Douglas Wilson) Date: Thu, 8 Feb 2018 12:32:17 +1300 Subject: Windows build broken -- help! In-Reply-To: References: Message-ID: Hi Simon, The first patch you quoted half-fixed this. the patch here: https://phabricator.haskell.org/D4392 should fix whole-fix it. (It at least validates green on windows) On Thu, Feb 8, 2018 at 12:18 PM, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > PS Presumably it’s these commits > > commit 00f1a4ab80b201ce15c509126f89c5a108786f32 > > Author: Douglas Wilson > > Date: Tue Feb 6 17:27:32 2018 -0500 > > > > rts: fix some barf format specifiers. > > > > Reviewers: bgamari, erikd, simonmar > > > > Reviewed By: bgamari > > > > Subscribers: rwbarton, thomie, carter > > > > Differential Revision: https://phabricator.haskell.org/D4390 > > > > commit 4d1c3b72ec27c8e51fb40809bba3ce35246a2966 > > Author: Ben Gamari > > Date: Tue Feb 6 13:27:35 2018 -0500 > > > > rts: Add format attribute to barf > > > > Test Plan: Validate > > > > Reviewers: erikd, simonmar > > > > Reviewed By: simonmar > > > > Subscribers: rwbarton, thomie, carter > > > > Differential Revision: https://phabricator.haskell.org/D4374 > > > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Simon > Peyton Jones via ghc-devs > *Sent:* 07 February 2018 23:14 > *To:* ghc-devs ; Phyx > *Subject:* Windows build broken -- help! > > > > Aargh. Windows build is broken again. Log below. Help! > > Simon > > > > "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall > -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes > -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline > -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn > -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes > -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header > -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build > -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common > -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 > -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" > -optc-DWINVER=0x06000100 -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage > -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header > -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build > -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build > -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen > -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgPrimFloat.c > -o rts/dist/build/StgPrimFloat.o > > > > rts\Schedule.c:274:14: error: > > error: unknown conversion type character 'l' in format > [-Werror=format=] > > barf("sched_state: %" FMT_Word, sched_state); > > ^~~~~~~~~~~~~~~~ > > | > > 274 | barf("sched_state: %" FMT_Word, sched_state); > > | ^ > > In file included from C:/code/HEAD-1/inplace/mingw/ > x86_64-w64-mingw32/include/stdio.h:1036:0, > > from includes/rts/Flags.h:16, > > from includes/Rts.h:191, > > > > from rts\Schedule.c:11:0: error: > > C:/code/HEAD-1/inplace/mingw/x86_64-w64-mingw32/include/_mingw_print_pop.h:86:18: > note: format string is defined here > > #define PRIu64 "llu" > > ^ > > > > rts\Schedule.c:274:14: error: > > error: too many arguments for format [-Werror=format-extra-args] > > barf("sched_state: %" FMT_Word, sched_state); > > ^~~~~~~~~~~~~~~~ > > | > > 274 | barf("sched_state: %" FMT_Word, sched_state); > > | ^ > > cc1.exe: all warnings being treated as errors > > `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) > > "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall > -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes > -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline > -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn > -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes > -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header > -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build > -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common > -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 > -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" > -optc-DWINVER=0x06000100 -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage > -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header > -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build > -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build > -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen > -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/Profiling.c -o > rts/dist/build/Profiling.o > > make[1]: *** [rts/ghc.mk:295: rts/dist/build/Schedule.o] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > make: *** [Makefile:127: all] Error 2 > > /c/code/HEAD-1$ > > _______________________________________________ > 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 Thu Feb 8 00:16:57 2018 From: lonetiger at gmail.com (lonetiger at gmail.com) Date: Thu, 8 Feb 2018 00:16:57 +0000 Subject: Windows build broken -- help! In-Reply-To: References: Message-ID: <5a7b96f9.8b8bdf0a.d9aaf.eacb@mx.google.com> I’ve pushed the commit. Thanks Doug! From: Douglas Wilson Sent: Wednesday, February 7, 2018 23:33 To: Simon Peyton Jones Cc: ghc-devs Subject: Re: Windows build broken -- help! Hi Simon, The first patch you quoted half-fixed this. the patch here: https://phabricator.haskell.org/D4392 should fix whole-fix it. (It at least validates green on windows) On Thu, Feb 8, 2018 at 12:18 PM, Simon Peyton Jones via ghc-devs wrote: PS Presumably it’s these commits commit 00f1a4ab80b201ce15c509126f89c5a108786f32 Author: Douglas Wilson Date:   Tue Feb 6 17:27:32 2018 -0500       rts: fix some barf format specifiers.         Reviewers: bgamari, erikd, simonmar         Reviewed By: bgamari         Subscribers: rwbarton, thomie, carter         Differential Revision: https://phabricator.haskell.org/D4390   commit 4d1c3b72ec27c8e51fb40809bba3ce35246a2966 Author: Ben Gamari Date:   Tue Feb 6 13:27:35 2018 -0500       rts: Add format attribute to barf         Test Plan: Validate         Reviewers: erikd, simonmar         Reviewed By: simonmar         Subscribers: rwbarton, thomie, carter         Differential Revision: https://phabricator.haskell.org/D4374     From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon Peyton Jones via ghc-devs Sent: 07 February 2018 23:14 To: ghc-devs ; Phyx Subject: Windows build broken -- help!   Aargh. Windows build is broken again.  Log below.  Help! Simon   "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-DWINVER=0x06000100 -static  -O0 -H64m -Wall -fllvm-fill-undef-with-garbage    -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint      -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen            -O2 -Wcpp-undef    -Wnoncanonical-monad-instances  -c rts/StgPrimFloat.c -o rts/dist/build/StgPrimFloat.o   rts\Schedule.c:274:14: error:      error: unknown conversion type character 'l' in format [-Werror=format=]              barf("sched_state: %" FMT_Word, sched_state);                   ^~~~~~~~~~~~~~~~     | 274 |         barf("sched_state: %" FMT_Word, sched_state);     |              ^ In file included from C:/code/HEAD-1/inplace/mingw/x86_64-w64-mingw32/include/stdio.h:1036:0,                  from includes/rts/Flags.h:16,                  from includes/Rts.h:191,                    from rts\Schedule.c:11:0: error: C:/code/HEAD-1/inplace/mingw/x86_64-w64-mingw32/include/_mingw_print_pop.h:86:18: note: format string is defined here #define PRIu64 "llu"                   ^   rts\Schedule.c:274:14: error:      error: too many arguments for format [-Werror=format-extra-args]              barf("sched_state: %" FMT_Word, sched_state);                   ^~~~~~~~~~~~~~~~     | 274 |         barf("sched_state: %" FMT_Word, sched_state);     |              ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-DWINVER=0x06000100 -static  -O0 -H64m -Wall -fllvm-fill-undef-with-garbage    -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint      -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen            -O2 -Wcpp-undef    -Wnoncanonical-monad-instances  -c rts/Profiling.c -o rts/dist/build/Profiling.o make[1]: *** [rts/ghc.mk:295: rts/dist/build/Schedule.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:127: all] Error 2 /c/code/HEAD-1$ _______________________________________________ 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 Thu Feb 8 08:23:13 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 8 Feb 2018 08:23:13 +0000 Subject: Windows build broken -- help! In-Reply-To: <5a7b96f9.8b8bdf0a.d9aaf.eacb@mx.google.com> References: <5a7b96f9.8b8bdf0a.d9aaf.eacb@mx.google.com> Message-ID: Yes thanks Doug… testing now From: lonetiger at gmail.com [mailto:lonetiger at gmail.com] Sent: 08 February 2018 00:17 To: Douglas Wilson ; Simon Peyton Jones Cc: ghc-devs Subject: RE: Windows build broken -- help! I’ve pushed the commit. Thanks Doug! From: Douglas Wilson Sent: Wednesday, February 7, 2018 23:33 To: Simon Peyton Jones Cc: ghc-devs Subject: Re: Windows build broken -- help! Hi Simon, The first patch you quoted half-fixed this. the patch here: https://phabricator.haskell.org/D4392 should fix whole-fix it. (It at least validates green on windows) On Thu, Feb 8, 2018 at 12:18 PM, Simon Peyton Jones via ghc-devs > wrote: PS Presumably it’s these commits commit 00f1a4ab80b201ce15c509126f89c5a108786f32 Author: Douglas Wilson > Date: Tue Feb 6 17:27:32 2018 -0500 rts: fix some barf format specifiers. Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4390 commit 4d1c3b72ec27c8e51fb40809bba3ce35246a2966 Author: Ben Gamari > Date: Tue Feb 6 13:27:35 2018 -0500 rts: Add format attribute to barf Test Plan: Validate Reviewers: erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4374 From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon Peyton Jones via ghc-devs Sent: 07 February 2018 23:14 To: ghc-devs >; Phyx > Subject: Windows build broken -- help! Aargh. Windows build is broken again. Log below. Help! Simon "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-DWINVER=0x06000100 -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgPrimFloat.c -o rts/dist/build/StgPrimFloat.o rts\Schedule.c:274:14: error: error: unknown conversion type character 'l' in format [-Werror=format=] barf("sched_state: %" FMT_Word, sched_state); ^~~~~~~~~~~~~~~~ | 274 | barf("sched_state: %" FMT_Word, sched_state); | ^ In file included from C:/code/HEAD-1/inplace/mingw/x86_64-w64-mingw32/include/stdio.h:1036:0, from includes/rts/Flags.h:16, from includes/Rts.h:191, from rts\Schedule.c:11:0: error: C:/code/HEAD-1/inplace/mingw/x86_64-w64-mingw32/include/_mingw_print_pop.h:86:18: note: format string is defined here #define PRIu64 "llu" ^ rts\Schedule.c:274:14: error: error: too many arguments for format [-Werror=format-extra-args] barf("sched_state: %" FMT_Word, sched_state); ^~~~~~~~~~~~~~~~ | 274 | barf("sched_state: %" FMT_Word, sched_state); | ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-DWINVER=0x06000100 -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/Profiling.c -o rts/dist/build/Profiling.o make[1]: *** [rts/ghc.mk:295: rts/dist/build/Schedule.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:127: all] Error 2 /c/code/HEAD-1$ _______________________________________________ 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 well-typed.com Thu Feb 8 19:57:58 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 08 Feb 2018 14:57:58 -0500 Subject: Can't typeset docs In-Reply-To: References: <878tc6yskq.fsf@smart-cactus.org> Message-ID: <87zi4jxni9.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > | > When I have > | > > | > BUILD_SPHINX_HTML = YES > | > > | > BUILD_SPHINX_PDF = YES > | > I get this error in my build. Any ideas? I think Sphinx is up to > | date. > | > Thanks > | > Simon > | > > | I suspect the cause here is the --no-clean, which doesn't run ./boot > | and ./configure. The latter generates docs/users_guide/ghc_config.py, > | which appears to be missing. Is the problem reproducible with a fresh > | validate? > > Thanks Ben. I think you are right -- sorry about that. I didn't know that you need to start from clean of you change those settings. > > But a fresh validate still fails, just differently. Tail of the log is below. There seem be two suspicious lines: > > Package cmap Warning: pdftex not detected - exiting. > > and later > (/usr/share/texlive/texmf-dist/doc/support/pedigree-perl/examples/english.cfg > ! You can't use `macro parameter character #' in vertical mode. > l.1 # > An example configuration file for pedigree program > No pages of output. > Hmm, judging from this [1] I would guess that this is a system configuration issue. Does your configuration set TEXINPUTS by any chance? Cheers, - Ben [1] https://tex.stackexchange.com/questions/91284/error-in-english-cfg -------------- 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 Feb 9 02:24:02 2018 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 9 Feb 2018 07:54:02 +0530 Subject: DoAndIfThenElse Message-ID: Hi, I recently found a mention of DoAndIfThenElse extension somewhere. I looked inside the ghc user guide and could not find any such extension. Then I looked in the ghc man page, no mention. I googled and found a very sparse references to it here and there. Then I tried using the extension with ghc and ghc seems to accept it. What's the story behind this, why is it not documented but accepted? thanks, harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Feb 9 02:38:59 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 8 Feb 2018 21:38:59 -0500 Subject: DoAndIfThenElse In-Reply-To: References: Message-ID: Huh. I wonder if a section went missing; seems like none of the extensions that alter or relax layout are documented currently. (AlternativeLayoutRule, AlternativeLayoutRuleTransitional, DoAndIfThenElse, NondecreasingIndentation, RelaxedLayout) IIRC DoAndIfThenElse relaxes a condition implied by layout but that normally only matters in "do": that if you break it into multiple lines, the "then" and "else" must be indented farther than the "if" or layout will consider them distinct new expressions (and thereby syntax errors). On Thu, Feb 8, 2018 at 9:24 PM, Harendra Kumar wrote: > Hi, > > I recently found a mention of DoAndIfThenElse extension somewhere. I > looked inside the ghc user guide and could not find any such extension. > Then I looked in the ghc man page, no mention. I googled and found a very > sparse references to it here and there. Then I tried using the extension > with ghc and ghc seems to accept it. What's the story behind this, why is > it not documented but accepted? > > thanks, > harendra > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- 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 moritz at lichtzwerge.de Fri Feb 9 02:42:37 2018 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Fri, 9 Feb 2018 10:42:37 +0800 Subject: DoAndIfThenElse In-Reply-To: References: Message-ID: <9F82B898-D105-483C-9179-CE8EA8BB2BA5@lichtzwerge.de> Hi, not sure if this helps. testsuite/tests/parser/should_compile/DoAndIfThenElse.hs gives us ``` {-# LANGUAGE DoAndIfThenElse #-} module DoAndIfThenElse where foo :: IO () foo = do if True then return () else return () ``` and there is some other mention in libraries/bytestring/bench/wiki-haskell.html, which states: ```

Haskell 2010 adds the foreign function interface (FFI) to Haskell, allowing for bindings to other programming languages, fixes some syntax issues (changes in the formal grammar) and bans so-called "n-plus-k-patterns", that is, definitions of the form fact (n+1) = (n+1) * fact n are no longer allowed. It introduces the Language-Pragma-Syntax-Extension which allows for designating a Haskell source as Haskell 2010 or requiring certain extensions to the Haskell language. The names of the extensions introduced in Haskell 2010 are DoAndIfThenElse, HierarchicalModules, EmptyDataDeclarations, FixityResolution, ForeignFunctionInterface, LineCommentSyntax, PatternGuards, RelaxedDependencyAnalysis, LanguagePragma and NoNPlusKPatterns.[1]

``` in compiler/main/DynFlags.hs we find ``` languageExtensions (Just Haskell2010) = [LangExt.ImplicitPrelude, LangExt.MonomorphismRestriction, LangExt.DatatypeContexts, LangExt.TraditionalRecordSyntax, LangExt.EmptyDataDecls, LangExt.ForeignFunctionInterface, LangExt.PatternGuards, LangExt.DoAndIfThenElse, LangExt.RelaxedPolyRec] ``` So, in Haskell2010, it's always on, and allows to write the above code. When we set NoDoAndIfThenElse, we get ``` Unexpected semi-colons in conditional: if True; then return (); else return () Perhaps you meant to use DoAndIfThenElse? ``` And then there's https://prime.haskell.org/wiki/DoAndIfThenElse. Cheers, Moritz > On Feb 9, 2018, at 10:24 AM, Harendra Kumar wrote: > > Hi, > > I recently found a mention of DoAndIfThenElse extension somewhere. I looked inside the ghc user guide and could not find any such extension. Then I looked in the ghc man page, no mention. I googled and found a very sparse references to it here and there. Then I tried using the extension with ghc and ghc seems to accept it. What's the story behind this, why is it not documented but accepted? > > thanks, > harendra > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From harendra.kumar at gmail.com Fri Feb 9 02:42:53 2018 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 9 Feb 2018 08:12:53 +0530 Subject: DoAndIfThenElse In-Reply-To: References: Message-ID: Since I started programming in Haskell a few years ago I have been using if-then-else in that manner without indentation and I never knew about this extension. I thought this is how it works. It seems this is the default now. But, I remember encountering an error in an older compiler version once and then I figured the my style was accepted in newer compiler versions only. -harendra On 9 February 2018 at 08:08, Brandon Allbery wrote: > Huh. I wonder if a section went missing; seems like none of the extensions > that alter or relax layout are documented currently. > (AlternativeLayoutRule, AlternativeLayoutRuleTransitional, > DoAndIfThenElse, NondecreasingIndentation, RelaxedLayout) > > IIRC DoAndIfThenElse relaxes a condition implied by layout but that > normally only matters in "do": that if you break it into multiple lines, > the "then" and "else" must be indented farther than the "if" or layout will > consider them distinct new expressions (and thereby syntax errors). > > On Thu, Feb 8, 2018 at 9:24 PM, Harendra Kumar > wrote: > >> Hi, >> >> I recently found a mention of DoAndIfThenElse extension somewhere. I >> looked inside the ghc user guide and could not find any such extension. >> Then I looked in the ghc man page, no mention. I googled and found a very >> sparse references to it here and there. Then I tried using the extension >> with ghc and ghc seems to accept it. What's the story behind this, why is >> it not documented but accepted? >> >> thanks, >> harendra >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > > > -- > 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 omeragacan at gmail.com Fri Feb 9 08:42:09 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 9 Feb 2018 11:42:09 +0300 Subject: StgLint worth maintaining? Message-ID: Hi, I've been looking into some StgLint-related tickets: - #13994: Found a StgLint problem and fixed, there's another problem waiting to be fixed. Both related with the fact that after unarisation we lose even more typing information and type checks needs to be relaxed. - #14116: StgLint failed to look through newtypes, and because coercions are removed at that point it failed to type check. Solution was to relax type checks. - #5345: Because `unsafeCoerce# is operationally no-op, and we don't have coercions in STG, StgLint can't type check at all. The commit message notes: > Fundamentally STG Lint is impossible, because unsafeCoerce# > can randomise all the types. > This patch does a bit of fiddle faddling in StgLint which > makes it a bit better, but it's a losing battle. - #14117: Related with StgLint not keeping up with recent changes (join points), because it's not enabled by default in tests/validate. - #14118: Related with the fact that pre- and post-unarise we have different invariants in STG. Solution was to add a "unarise" parameter and do different checks based on that. - #14120: Again type checking errors. Commit for #14116 also fixes this. The commits compares `typePrimRep`s of types instead of comparing actual types (even this is not enough, see #13994). All this of course took time to debug. In addition, the new `StgCSE` pass makes transformations that trigger case alternative checks (and probably some other checks) because scrutinee and result won't have same types after the transformation described in `Note [Case 2: CSEing case binders]`. There's also this comment in StgLint.hs WARNING: ~~~~~~~~ This module has suffered bit-rot; it is likely to yield lint errors for Stg code that is currently perfectly acceptable for code generation. Solution: don't use it! (KSW 2000-05). It seems like it hasn't been used since 2000. All this suggests that - Checks related to types are impossible in StgLint. (see e.g. commit messages in #5345, #1420, transformations done by unariser and StgCSE) - It's not enabled since 2000, which I think means that it's not needed. This makes me question whether it's worth maintaining. Maybe we should just remove it. If we still want to keep we should decide on what it's supposed to do. Only invariants I can think of are: - After unarise there should be no unboxed tuple and sum binders. unarise is a simple pass and does same thing to all binders, there are no tricky cases so I'm not sure if we need to check this. - Variables should be defined before use. I again don't know if this should be checked, could this be useful for StgCSE? So I think we should do one of these: 1. Remove StgLint. 2. Rewrite it to only check these two and nothing else, enable it in validate (and in other build flavours that enable CoreLint). What do you think? If you think we should keep StgLint, can you think of any other checks? If we could reach a consensus I'm hoping to update StgLint (or remove it). Thanks, Ömer From simonpj at microsoft.com Fri Feb 9 09:22:24 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 9 Feb 2018 09:22:24 +0000 Subject: StgLint worth maintaining? In-Reply-To: References: Message-ID: Good summary! I suggest that you open a ticket with this email as the Description. Then we can point to it later. I agree that there is little point in flogging a dead horse. But there are /some/ invariants, so I vote for | 2. Rewrite it to only check these two and nothing else, enable it in | validate (and in other build flavours that enable CoreLint). | Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ömer | Sinan Agacan | Sent: 09 February 2018 08:42 | To: ghc-devs | Subject: StgLint worth maintaining? | | Hi, | | I've been looking into some StgLint-related tickets: | | - #13994: Found a StgLint problem and fixed, there's another problem | waiting to be fixed. Both related with the fact that after | unarisation we lose even more typing information and type | checks needs to be relaxed. | | - #14116: StgLint failed to look through newtypes, and because | coercions | are removed at that point it failed to type check. Solution | was to relax type checks. | | - #5345: Because `unsafeCoerce# is operationally no-op, and we don't | have coercions in STG, StgLint can't type check at all. The | commit message notes: | | > Fundamentally STG Lint is impossible, because | unsafeCoerce# | > can randomise all the types. | | > This patch does a bit of fiddle faddling in StgLint which | > makes it a bit better, but it's a losing battle. | | - #14117: Related with StgLint not keeping up with recent changes | (join | points), because it's not enabled by default in | tests/validate. | | - #14118: Related with the fact that pre- and post-unarise we have | different invariants in STG. Solution was to add a "unarise" | parameter and do different checks based on that. | | - #14120: Again type checking errors. Commit for #14116 also fixes | this. | The commits compares `typePrimRep`s of types instead of | comparing actual types (even this is not enough, see | #13994). | | All this of course took time to debug. | | In addition, the new `StgCSE` pass makes transformations that trigger | case alternative checks (and probably some other checks) because | scrutinee and result won't have same types after the transformation | described in `Note [Case 2: CSEing case binders]`. | | There's also this comment in StgLint.hs | | WARNING: | ~~~~~~~~ | | This module has suffered bit-rot; it is likely to yield lint | errors | for Stg code that is currently perfectly acceptable for code | generation. Solution: don't use it! (KSW 2000-05). | | It seems like it hasn't been used since 2000. | | All this suggests that | | - Checks related to types are impossible in StgLint. (see e.g. commit | messages in #5345, #1420, transformations done by unariser and | StgCSE) | | - It's not enabled since 2000, which I think means that it's not | needed. | | This makes me question whether it's worth maintaining. Maybe we should | just remove it. | | If we still want to keep we should decide on what it's supposed to do. | Only invariants I can think of are: | | - After unarise there should be no unboxed tuple and sum binders. | | unarise is a simple pass and does same thing to all binders, there | are | no tricky cases so I'm not sure if we need to check this. | | - Variables should be defined before use. I again don't know if this | should be checked, could this be useful for StgCSE? | | So I think we should do one of these: | | 1. Remove StgLint. | | 2. Rewrite it to only check these two and nothing else, enable it in | validate (and in other build flavours that enable CoreLint). | | What do you think? If you think we should keep StgLint, can you think | of any other checks? If we could reach a consensus I'm hoping to | update StgLint (or remove it). | | Thanks, | | Ömer | _______________________________________________ | 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%7C9d9affa423c84c84a25908d5 | 6f992d87%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C6365376260479856 | 64%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI | 6Ik1haWwifQ%3D%3D%7C- | 1&sdata=GZ4xMoVQGyQFZxhlODBqMnWoiZrV82pqOn2ZrbvDo4U%3D&reserved=0 From simonpj at microsoft.com Fri Feb 9 09:24:21 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 9 Feb 2018 09:24:21 +0000 Subject: DoAndIfThenElse In-Reply-To: References: Message-ID: At very least the extension should be documented! Would you like to open a ticket for that? And even offer a patch? Thanks for pointing this out. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Harendra Kumar Sent: 09 February 2018 02:43 To: Brandon Allbery Cc: ghc-devs at haskell.org Devs Subject: Re: DoAndIfThenElse Since I started programming in Haskell a few years ago I have been using if-then-else in that manner without indentation and I never knew about this extension. I thought this is how it works. It seems this is the default now. But, I remember encountering an error in an older compiler version once and then I figured the my style was accepted in newer compiler versions only. -harendra On 9 February 2018 at 08:08, Brandon Allbery > wrote: Huh. I wonder if a section went missing; seems like none of the extensions that alter or relax layout are documented currently. (AlternativeLayoutRule, AlternativeLayoutRuleTransitional, DoAndIfThenElse, NondecreasingIndentation, RelaxedLayout) IIRC DoAndIfThenElse relaxes a condition implied by layout but that normally only matters in "do": that if you break it into multiple lines, the "then" and "else" must be indented farther than the "if" or layout will consider them distinct new expressions (and thereby syntax errors). On Thu, Feb 8, 2018 at 9:24 PM, Harendra Kumar > wrote: Hi, I recently found a mention of DoAndIfThenElse extension somewhere. I looked inside the ghc user guide and could not find any such extension. Then I looked in the ghc man page, no mention. I googled and found a very sparse references to it here and there. Then I tried using the extension with ghc and ghc seems to accept it. What's the story behind this, why is it not documented but accepted? thanks, harendra _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- 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 Feb 9 09:29:55 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 9 Feb 2018 09:29:55 +0000 Subject: DoAndIfThenElse In-Reply-To: References: Message-ID: I also recall that Idris and Elm have some do-syntax like this: do { x <- e1 ; Just y <- e2 | Nothing -> exceptional-code ; etc ; etc } That is, e2 :: blah -> IO (Maybe t), we can pattern match on the expected Just case, but still provide code for the Nothing case. That’s much better than do { x <- e1 ; mb_y <- e2 ; case mb_y of Nothing -> exceptional-code Just y -> do { etc etc } } I’d love this for Haskell, if someone felt like making a proposal. I do this kind of thing all the time! Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Harendra Kumar Sent: 09 February 2018 02:43 To: Brandon Allbery Cc: ghc-devs at haskell.org Devs Subject: Re: DoAndIfThenElse Since I started programming in Haskell a few years ago I have been using if-then-else in that manner without indentation and I never knew about this extension. I thought this is how it works. It seems this is the default now. But, I remember encountering an error in an older compiler version once and then I figured the my style was accepted in newer compiler versions only. -harendra On 9 February 2018 at 08:08, Brandon Allbery > wrote: Huh. I wonder if a section went missing; seems like none of the extensions that alter or relax layout are documented currently. (AlternativeLayoutRule, AlternativeLayoutRuleTransitional, DoAndIfThenElse, NondecreasingIndentation, RelaxedLayout) IIRC DoAndIfThenElse relaxes a condition implied by layout but that normally only matters in "do": that if you break it into multiple lines, the "then" and "else" must be indented farther than the "if" or layout will consider them distinct new expressions (and thereby syntax errors). On Thu, Feb 8, 2018 at 9:24 PM, Harendra Kumar > wrote: Hi, I recently found a mention of DoAndIfThenElse extension somewhere. I looked inside the ghc user guide and could not find any such extension. Then I looked in the ghc man page, no mention. I googled and found a very sparse references to it here and there. Then I tried using the extension with ghc and ghc seems to accept it. What's the story behind this, why is it not documented but accepted? thanks, harendra _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- 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 Feb 9 09:34:12 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 9 Feb 2018 09:34:12 +0000 Subject: about GHC API: Looking up names In-Reply-To: References: Message-ID: Ranjit Have you read Note [The equality types story] in compiler/prelude/TysPrim? As you’ll see (~) is actually a class; the equality predicate is (~#). There doesn’t seems to be a named-function predicate that checks for it explicitly, but if you grep for eqTyCon you’ll see lots of tests for it. I’m sure these tests could be tideied up into a smaller collection of predicates. Simon From: rjhala at eng.ucsd.edu [mailto:rjhala at eng.ucsd.edu] On Behalf Of Ranjit Jhala Sent: 09 February 2018 04:41 To: Simon Peyton Jones Subject: Re: about GHC API: Looking up names Dear Simon, still working on the above, but hit an odd problem on the way. How can I "test for" (i.e. write a function of type `Type -> Bool`) that returns `True` for values (i.e. `Type`s) that print out as: typ ~ GHC.Types.Int or with, which some more detail, looks like (~ (TYPE LiftedRep) typ GHC.Types.Int) I would have thought that `Type.isEqPred` or `Type.isNomEqPred` described here https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/ghc-8.2.1/src/Type.html#isEqPred would work, but apparently not? Any clues? Thanks! - Ranjit. On Thu, Feb 1, 2018 at 8:25 AM, Ranjit Jhala > wrote: Will do! Best, Ranjit. On Thu, Feb 1, 2018 at 5:20 AM, Simon Peyton Jones > wrote: I’m glad you are un-glued, but it smells wrong to me and your solution seems like a workaround for a bug, not the Right Path. Could you make a ticket with a repro case? Thanks! Simon From: rjhala at eng.ucsd.edu [mailto:rjhala at eng.ucsd.edu] On Behalf Of Ranjit Jhala Sent: 31 January 2018 19:14 To: Simon Peyton Jones > Subject: Re: about GHC API: Looking up names Dear Simon, No worries, I was able to figure it out, or at least work around it. > It’s very mysterious that declaring it in an > instance decl would make any difference. It looks like that is exactly what is happening, but perhaps by design? (I saw there was something called an `ImplicitTyThing` that are not in the top-level scope, so I figured that perhaps these instance declarations were "implicit" and hence not available?) Nevertheless, I was able to work around the issue by using `tcGetFamInstEnvs` to get the `FamInstEnv` and from that, making my own lookup environment (comprising the TyCon and DataCon for the family instances.) This works for my purposes, but if the above is a possible bug, I can try to make a small test case? Thanks! - Ranjit. On Wed, Jan 31, 2018 at 1:47 AM, Simon Peyton Jones > wrote: Hi Ranjit That does sound odd. You should ask on ghc-devs too… though you may already have done that. hscTcRnLookupName doesn’t do anything fancy: it just looks up the Name in the type environment. It’s very mysterious that declaring it in an instance decl would make any difference. I suppose you could somehow have gotten hold of the wrong Name. If I was debugging it, I’d start spitting out traces showing the type environment it is looking up in, to see what is there and what is not. If you make a small standalone test case (e.g. a tiny client of the GHC API that demonstrates the problem) that could enable others to reproduce and help you. Or, I guess, we could do a Skype chat with you trying things locally. I wish I could help more Simon From: rjhala at eng.ucsd.edu [mailto:rjhala at eng.ucsd.edu] On Behalf Of Ranjit Jhala Sent: 26 January 2018 02:12 To: Simon Peyton Jones > Subject: Q: about GHC API: Looking up names Dear Simon, I have a question about the GHC API I wonder you can help with? Suppose `Library.hs` is has the constructors defined in the simple top-level style: ``` data EntityField typ where BlobXVal :: EntityField Int BlobYVal :: EntityField Int ``` Then when analyzing `Client.hs` (that imports `Library`), the lookup function `hscTcRcLookupName` WORKS just fine to give me the `TyThing` corresponding to the name “BlobXVal”. However, if instead, Library.hs defines the constructors within an instance: ``` instance PersistEntity Blob where data EntityField Blob typ where BlobXVal :: EntityField Blob Int BlobYVal :: EntityField Blob Int ``` then, when analyzing Client.hs, the `hscTcRcLookupName` function FAILS to resolve the name. Clearly there is some difference in how `hscTcRcLookupName` works in these two cases. Does you know what it is? Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at justus.science Sat Feb 10 10:16:35 2018 From: dev at justus.science (Development) Date: Sat, 10 Feb 2018 11:16:35 +0100 Subject: User constructed types with new Data.Typeable and Data.Reflection Message-ID: <78655C80-D5FF-46D4-9748-239F34FDD382@justus.science> Hey guys I have a (hopefully quick) question. With the new `Data.Typeable` and `Data.Reflection` in base 4.10 have we really lost the ability for users to compose `TypeRep`’s? I was using `Data.Typeable` before (mainly `mkTyConApp`). But in the new base 4.10 I cannot find any way to achieve the same goal. I have read the wiki page Typeable and Typeable/BenGamari and neither explicitly mentions the removal of `mkTyConApp` and similar facilities. In fact the latter mentions potential implementations for user constructed type applications twice with `mkTrApp` at the beginning of the page and `mkApp` at the end. Furthermore the documentation for `Typeable` (and `Reflection`) also never mentions the fact that this functionality was removed. My question is this: Is this intentional? Is there now a consensus that there should not be user constructed types? Or is there some subtile issue that I’m missing wich prevents user constructed types for now or always? Thanks in advance guys. Best regards. Justus From omeragacan at gmail.com Sat Feb 10 15:09:05 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sat, 10 Feb 2018 18:09:05 +0300 Subject: StgLint worth maintaining? In-Reply-To: References: Message-ID: Created #14787 as tracking ticket. Patch is at D4404. Ömer 2018-02-09 12:22 GMT+03:00 Simon Peyton Jones : > Good summary! I suggest that you open a ticket with this email as the Description. Then we can point to it later. > > I agree that there is little point in flogging a dead horse. But there are /some/ invariants, so I vote for > | 2. Rewrite it to only check these two and nothing else, enable it in > | validate (and in other build flavours that enable CoreLint). > | > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ömer > | Sinan Agacan > | Sent: 09 February 2018 08:42 > | To: ghc-devs > | Subject: StgLint worth maintaining? > | > | Hi, > | > | I've been looking into some StgLint-related tickets: > | > | - #13994: Found a StgLint problem and fixed, there's another problem > | waiting to be fixed. Both related with the fact that after > | unarisation we lose even more typing information and type > | checks needs to be relaxed. > | > | - #14116: StgLint failed to look through newtypes, and because > | coercions > | are removed at that point it failed to type check. Solution > | was to relax type checks. > | > | - #5345: Because `unsafeCoerce# is operationally no-op, and we don't > | have coercions in STG, StgLint can't type check at all. The > | commit message notes: > | > | > Fundamentally STG Lint is impossible, because > | unsafeCoerce# > | > can randomise all the types. > | > | > This patch does a bit of fiddle faddling in StgLint which > | > makes it a bit better, but it's a losing battle. > | > | - #14117: Related with StgLint not keeping up with recent changes > | (join > | points), because it's not enabled by default in > | tests/validate. > | > | - #14118: Related with the fact that pre- and post-unarise we have > | different invariants in STG. Solution was to add a "unarise" > | parameter and do different checks based on that. > | > | - #14120: Again type checking errors. Commit for #14116 also fixes > | this. > | The commits compares `typePrimRep`s of types instead of > | comparing actual types (even this is not enough, see > | #13994). > | > | All this of course took time to debug. > | > | In addition, the new `StgCSE` pass makes transformations that trigger > | case alternative checks (and probably some other checks) because > | scrutinee and result won't have same types after the transformation > | described in `Note [Case 2: CSEing case binders]`. > | > | There's also this comment in StgLint.hs > | > | WARNING: > | ~~~~~~~~ > | > | This module has suffered bit-rot; it is likely to yield lint > | errors > | for Stg code that is currently perfectly acceptable for code > | generation. Solution: don't use it! (KSW 2000-05). > | > | It seems like it hasn't been used since 2000. > | > | All this suggests that > | > | - Checks related to types are impossible in StgLint. (see e.g. commit > | messages in #5345, #1420, transformations done by unariser and > | StgCSE) > | > | - It's not enabled since 2000, which I think means that it's not > | needed. > | > | This makes me question whether it's worth maintaining. Maybe we should > | just remove it. > | > | If we still want to keep we should decide on what it's supposed to do. > | Only invariants I can think of are: > | > | - After unarise there should be no unboxed tuple and sum binders. > | > | unarise is a simple pass and does same thing to all binders, there > | are > | no tricky cases so I'm not sure if we need to check this. > | > | - Variables should be defined before use. I again don't know if this > | should be checked, could this be useful for StgCSE? > | > | So I think we should do one of these: > | > | 1. Remove StgLint. > | > | 2. Rewrite it to only check these two and nothing else, enable it in > | validate (and in other build flavours that enable CoreLint). > | > | What do you think? If you think we should keep StgLint, can you think > | of any other checks? If we could reach a consensus I'm hoping to > | update StgLint (or remove it). > | > | Thanks, > | > | Ömer > | _______________________________________________ > | 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%7C9d9affa423c84c84a25908d5 > | 6f992d87%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C6365376260479856 > | 64%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI > | 6Ik1haWwifQ%3D%3D%7C- > | 1&sdata=GZ4xMoVQGyQFZxhlODBqMnWoiZrV82pqOn2ZrbvDo4U%3D&reserved=0 From ekmett at gmail.com Sat Feb 10 22:00:24 2018 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 10 Feb 2018 17:00:24 -0500 Subject: User constructed types with new Data.Typeable and Data.Reflection In-Reply-To: <78655C80-D5FF-46D4-9748-239F34FDD382@justus.science> References: <78655C80-D5FF-46D4-9748-239F34FDD382@justus.science> Message-ID: Did you mean Type.Reflection? (reflection's Data.Reflection offers a completely unrelated notion of Typeable reflection, hence my confusion.) -Edward On Sat, Feb 10, 2018 at 5:16 AM, Development wrote: > Hey guys I have a (hopefully quick) question. > > With the new `Data.Typeable` and `Data.Reflection` in base 4.10 have we > really lost the ability for users to compose `TypeRep`’s? > > I was using `Data.Typeable` before (mainly `mkTyConApp`). But in the new > base 4.10 I cannot find any way to achieve the same goal. > I have read the wiki page Typeable and Typeable/BenGamari and neither > explicitly mentions the removal of `mkTyConApp` and similar facilities. In > fact the latter mentions potential implementations for user constructed > type applications twice with `mkTrApp` at the beginning of the page and > `mkApp` at the end. > Furthermore the documentation for `Typeable` (and `Reflection`) also never > mentions the fact that this functionality was removed. > > My question is this: Is this intentional? Is there now a consensus that > there should not be user constructed types? Or is there some subtile issue > that I’m missing wich prevents user constructed types for now or always? > > Thanks in advance guys. > > Best regards. > > Justus > _______________________________________________ > 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 Mon Feb 12 17:30:55 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 12 Feb 2018 12:30:55 -0500 Subject: User constructed types with new Data.Typeable and Data.Reflection In-Reply-To: <78655C80-D5FF-46D4-9748-239F34FDD382@justus.science> References: <78655C80-D5FF-46D4-9748-239F34FDD382@justus.science> Message-ID: <87r2pqw1x2.fsf@smart-cactus.org> Development writes: > Hey guys I have a (hopefully quick) question. > > With the new `Data.Typeable` and `Data.Reflection` in base 4.10 have we really lost the ability for users to compose `TypeRep`’s? > > I was using `Data.Typeable` before (mainly `mkTyConApp`). But in the > new base 4.10 I cannot find any way to achieve the same goal. > > I have read the wiki page Typeable and Typeable/BenGamari and neither > explicitly mentions the removal of `mkTyConApp` and similar > facilities. In fact the latter mentions potential implementations for > user constructed type applications twice with `mkTrApp` at the > beginning of the page and `mkApp` at the end. > Furthermore the documentation for `Typeable` (and `Reflection`) also > never mentions the fact that this functionality was removed. > Indeed, as is noted in the changelog for base [1], mkTyConApp and friends were removed. mkTyConApp in particular allowed the construction of ill-kinded type representations so instead of emulating the previous behavior we rather opted to remove it. If you were previously using these interfaces you almost certainly want to instead use the new type-indexed interface provided by Type.Reflection. In particular, you can use the App constructor in place of mkTyConApp. Cheers, - Ben [1] https://hackage.haskell.org/package/base-4.10.1.0/changelog -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From dev at justus.science Tue Feb 13 10:49:18 2018 From: dev at justus.science (Development) Date: Tue, 13 Feb 2018 11:49:18 +0100 Subject: User constructed types with new Data.Typeable and Data.Reflection In-Reply-To: <87r2pqw1x2.fsf@smart-cactus.org> References: <78655C80-D5FF-46D4-9748-239F34FDD382@justus.science> <87r2pqw1x2.fsf@smart-cactus.org> Message-ID: <9A3AECE8-EF3F-4EB3-95A2-C66D092DF839@justus.science> Ah thanks. I had no idea the `App` pattern actually was bidirectional. I had tried the `Con’` pattern but that is only valid for deconstruction. Is there any way to tell in the docs whether a pattern is bidirectional? > On 12 Feb 2018, at 18:30, Ben Gamari wrote: > > Development writes: > >> Hey guys I have a (hopefully quick) question. >> >> With the new `Data.Typeable` and `Data.Reflection` in base 4.10 have we really lost the ability for users to compose `TypeRep`’s? >> >> I was using `Data.Typeable` before (mainly `mkTyConApp`). But in the >> new base 4.10 I cannot find any way to achieve the same goal. >> >> I have read the wiki page Typeable and Typeable/BenGamari and neither >> explicitly mentions the removal of `mkTyConApp` and similar >> facilities. In fact the latter mentions potential implementations for >> user constructed type applications twice with `mkTrApp` at the >> beginning of the page and `mkApp` at the end. >> Furthermore the documentation for `Typeable` (and `Reflection`) also >> never mentions the fact that this functionality was removed. >> > > Indeed, as is noted in the changelog for base [1], mkTyConApp and > friends were removed. mkTyConApp in particular allowed the construction > of ill-kinded type representations so instead of emulating the previous > behavior we rather opted to remove it. > > If you were previously using these interfaces you almost certainly want > to instead use the new type-indexed interface provided by > Type.Reflection. In particular, you can use the App constructor in > place of mkTyConApp. > > Cheers, > > - Ben > > > [1] https://hackage.haskell.org/package/base-4.10.1.0/changelog From hvriedel at gmail.com Tue Feb 13 13:35:10 2018 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 13 Feb 2018 14:35:10 +0100 Subject: [Haskell-cafe] GHC 8.2.2 for WSL Ubuntu 16.04 In-Reply-To: References: Message-ID: Hello *, Even though WSL may eventually address this issue for good, I've setup a new WSL-optimised flavour of my PPA for Ubuntu 16.04 LTS https://launchpad.net/~hvr/+archive/ubuntu/ghc over at https://launchpad.net/~hvr/+archive/ubuntu/ghc-wsl I don't have experience myself with Ubuntu on WSL, but it should be simply a matter of using sudo add-apt-repository ppa:hvr/ghc-wsl sudo apt-get update and then sudo apt-get install ghc-8.2.2-prof cabal-install-head Then simply add `/opt/ghc/bin` to your `$PATH` (see instructions at https://launchpad.net/~hvr/+archive/ubuntu/ghc ) There are also builds of GHC 8.0.2 and GHC 8.4.1-alpha (may still be building as of writing) in this new ghc-for-wsl PPA. I'd appreciate if somebody could test whether these GHC binaries work as intended on the non-insider Windows 10 builds and let me know. Cheers, Herbert On Tue, Feb 13, 2018 at 12:21 PM, Yitzchak Gale wrote: > I wrote: >>> I have made available a build of GHC 8.2.2 with the config option: >>> --disable-large-address-space >>> [2] https://github.com/Microsoft/WSL/issues/1671 > > Shao Cheng wrote: >> Thank you! A simpler fix for WSL ghc users is upgrading to fast ring of >> insider builds, the mmap overhead is much lower and ghc startup lag is >> barely noticable. > > Thanks, that's good news. I can't use an insider build - I need to be on > standard Windows in order to support our customers. The latest reports > in the GitHub issue seemed to indicate that the slowness is still quite > significant even on insider builds. I'm glad to hear you say that this is no > longer true. I am looking forward to regular GHC binary tarballs working > normally on regular WSL sometime in the near future. > > Yitz > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From mail at joachim-breitner.de Tue Feb 13 16:34:47 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 13 Feb 2018 11:34:47 -0500 Subject: testsuite failures in DEBUG In-Reply-To: <1517026993.17652.6.camel@joachim-breitner.de> References: <1517026993.17652.6.camel@joachim-breitner.de> Message-ID: <1518539687.3011.3.camel@joachim-breitner.de> Hi, Am Freitag, den 26.01.2018, 23:23 -0500 schrieb Joachim Breitner: > Am Freitag, den 26.01.2018, 22:53 -0500 schrieb Richard Eisenberg: > > So: would it be possible to have our CI infrastructure validate DEBUG mode as well? Then it would be easy to spot where these failures are from. > > unhelpful comment: Travis used to validate with DEBUG, but it no longer > runs the test suite for build time reason. So plausibly we could add a > -DEBUG variant to CircleCI? I now also stumble about the inability to properly test a build built with -DDEBUG. So let me rephrase: Could we please add a -DDEBUG variant to CircleCI? (And then fix the failing tests, or at least mark them as known-to-be- failing on a debugged GHC) Cheers, 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 ben at smart-cactus.org Tue Feb 13 20:33:26 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 13 Feb 2018 15:33:26 -0500 Subject: User constructed types with new Data.Typeable and Data.Reflection In-Reply-To: <9A3AECE8-EF3F-4EB3-95A2-C66D092DF839@justus.science> References: <78655C80-D5FF-46D4-9748-239F34FDD382@justus.science> <87r2pqw1x2.fsf@smart-cactus.org> <9A3AECE8-EF3F-4EB3-95A2-C66D092DF839@justus.science> Message-ID: <87o9kswrxq.fsf@smart-cactus.org> Development writes: > Ah thanks. I had no idea the `App` pattern actually was bidirectional. I had tried the `Con’` pattern but that is only valid for deconstruction. > Is there any way to tell in the docs whether a pattern is bidirectional? > Hmmm, that is a good question. Indeed this appears to be quite unclear. Alex, is this a known issue? 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 klebinger.andreas at gmx.at Wed Feb 14 19:51:18 2018 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Wed, 14 Feb 2018 20:51:18 +0100 Subject: Looking for GSoC Mentor Message-ID: <5A849336.80203@gmx.at> Hello Everyone, I'm looking for a mentor for a GSoC Project/Proposal. The whole idea revolves around: * Getting hot path information from static analysis and user annotations. * Making sure it's not destroyed by optimization passes. * Using it to generate better code where applicable. See also: #14672: Make likelihood of branches/conditions available throughout the compiler. Towards these goals I would like for GSoC: * Land https://phabricator.haskell.org/D4327(Branchweights in STG and Cmm) + It might be ready before then. But it's a prerequisite so worth listing here. * Design and implement a way for users to: + Mark hot paths in Haskell code. + Push the information through the passes (up to STG) on a best effort basis. STG and beyond is part of the diff above. + The current backend already uses this information in some places, so this alone should lead to small but consistent gains. + I don't plan to add additional optimizations unless there is time left at the end. Where I think I will need help/experience from a mentor is: * Frontend questions: I haven't looked at GHC's parser/renamer yet so while this is surmountable I expect some questions to arise there. * Design questions/feedback: Things like: + How should the user be able to give this information. + What should be flag controlled? What always on? + Things like compile time/executable speed tradeoffs. ... * Potentially the simplifier: I've looked into it briefly as originally D4327 was aimed at the core stage instead of stg. There doesn't seem to be a lot that could mess with hot path information/branchweights. But I haven't worked on the simplifier before and it seems like a good place for unexpected issues to arise. * If this involves the proposal process then also guidance there. For myself: * I'm studying at TU Vienna (Software & Information Engineering) and am close to finishing my undergrad. Located in Austria (UTC+1) * I have contributed a few small changes to GHC throughout last year. See AndreasK on Phab/Trac. * If you want to know more contact me! If you are interested in mentoring me or looking for more details feel free to contact me at klebinger.andreas at gmx.at or look for AndreasK in #ghc Best Regards Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Wed Feb 14 22:38:23 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 14 Feb 2018 17:38:23 -0500 Subject: testsuite failures in DEBUG In-Reply-To: <1518539687.3011.3.camel@joachim-breitner.de> References: <1517026993.17652.6.camel@joachim-breitner.de> <1518539687.3011.3.camel@joachim-breitner.de> Message-ID: <873723w61x.fsf@smart-cactus.org> Joachim Breitner writes: > Hi, > > Am Freitag, den 26.01.2018, 23:23 -0500 schrieb Joachim Breitner: >> Am Freitag, den 26.01.2018, 22:53 -0500 schrieb Richard Eisenberg: >> > So: would it be possible to have our CI infrastructure validate >> > DEBUG mode as well? Then it would be easy to spot where these >> > failures are from. >> >> unhelpful comment: Travis used to validate with DEBUG, but it no longer >> runs the test suite for build time reason. So plausibly we could add a >> -DEBUG variant to CircleCI? > > I now also stumble about the inability to properly test a build built > with -DDEBUG. > > So let me rephrase: Could we please add a -DDEBUG variant to CircleCI? > See D4411. > (And then fix the failing tests, or at least mark them as known-to-be- > failing on a debugged GHC) I'll add this to my list. 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 gershomb at gmail.com Mon Feb 19 00:14:21 2018 From: gershomb at gmail.com (Gershom B) Date: Sun, 18 Feb 2018 19:14:21 -0500 Subject: [GHC DevOps Group] Release policies In-Reply-To: References: <0383353F-5894-4993-96E2-71EEE64E3CB5@justtesting.org> Message-ID: This proposal seems to have trailed off. I think it is worth putting a bow on it and getting it signed off on for the GHC release policy page. Let me restate it: Bundled library maintainers agree to the following responsibilities: 1) When GHC cuts a feature-freeze branch, they too (if anything has changed) cut a feature-freeze branch within two weeks at the maximum (ideally sooner), to be included in the main GHC freeze branch. If they do not do so, the last released version will be included instead. 2) When GHC releases the first release candidate, maintainers (if anything has changed) release new versions of their packages, to then be depended on directly in the GHC repo. All submodules are then replaced with their proper released versions for GHC release. I know Chak and I had a back and forth, but I consider it resolved in the direction of this proposal at this point, as a strict improvement over the current situation that does not seem to invite further controversy. If in the event of future things we learn, this proposal is inadequate, we can revisit then. The one thing missing from both this proposal and the current release policy page in general is discussion of the head overlay to hackage. I think discussion of this should be integrated in both as a separate issue. In particular — the feature freeze branches of bundled libraries can and should be regularly updated in the head overlay. Thoughts? —Gershom On December 19, 2017 at 8:53:22 PM, Gershom B (gershomb at gmail.com) wrote: On December 19, 2017 at 8:15:49 PM, Manuel M T Chakravarty ( chak at justtesting.org) wrote: > > > This in particular implies that everything merged to the release > branch has to have been well tested (the wiki page states, ”[o]nly > previously agreed on, stable and tested new functionality is > allowed in.”) Ok — here’s where I get confused. In my experience, “well tested” is a relative term. Certainly if we want a three month period between branch and release, that’s because we’re expecting a _fair amount_ of bugs to shake out over that period. As you point out, the wiki page says “agreed on, stable and tested.” But nonetheless — that’s leaving a fair amount of room for bugs to be found. Since there’s a period when features are written, and another in which focus is all on bugfixing, then this is to be expected. Keeping moving the barrier for making it into even a _branch_ higher and higher seems weird to me. We’re already creating a new set of significant barriers by even starting to have this branch process at all. > Implicitly adding new functionality by depending > on a moving library dependency, which is out of the quality control > of the GHC team, is not something that I would call ”stable and > tested functionality”. And now here’s where you lose me entirely. The point is you wouldn’t be depending on a moving library dependency. You’d be depending on a _release branch_ just the same as GHC. Unless you mean to say that we shouldn’t trust the maintainers of bundled packages to only put “stable and tested” features in to a release branch? In the abstract, sure. If we were just including random github repos sourced from stackoverflow answers, sure. But in the actual concrete history of GHC and Haskell development — we know the maintainers of these libs. We know they move slowly in general, and they have processes too. And we know that if these libs, which are hard to upgrade on their own (because they’re bundled with GHC), are going to get a wide exposure to not just internal tests, but external users, it will be via being bundled with GHC. Since I would expect, based on past experience, that bundled libraries will often need small bugfixes and tweaks, as you agree, then what you’ve just sort of proposed is that we release extra versions of them that end up not bundled with GHC versions, and which are less well tested. What is the difference between cutting a branch and depending on it, which is what I propose, and what you propose, except that we’ll end up with extra version bumps in your scheme, and hackage packages with bugs that haven’t had a chance to be shaken out, and may, in some cases (integer-gmp, ghc-prim, base), not even make _sense_ outside of a GHC release. I understand that its not pleasant, but GHC and the bundled packages have, for the time being, a very special relationship. We can’t decouple them by administrative fiat. GHC depends on them, and they also need GHC to run. So their lifecycles are intertwined, and their development processes are intertwined. This is how they have been developed and maintained for years. Why do we suddenly want to pretend that now these maintainers are “out of the quality control of the GHC team” like they’re foreign entities? I also want to underline this is not about “new library features” as such — this is about cross-cutting development of the sort Moritz described that requires modifying GHC and bundled libs both. Another element of the two-way character of this relationship is that when GHC develops a new feature, often it is the bundled libs that are the first to take advantage of it — and this is a good thing, as it allows further stress-testing of the feature. (And sometimes, with certain deprication warnings, etc., the feature is even especially _for_ those libs). But if the feature turns out to need tweaks in the stability period (and this is far from unheard of) then it is the bundled libs that need to change to adapt. If you have already pinned yourself to released versions of libs, this is very hard! It would be nice if bundled libs were upstream of GHC, but they’re not, so we should stop pretending. Everyone’s in the same stream together, and everyone will have to agree to row :-) Again — what is objectionable to having a release branch cut instead of a full release at T-3? What danger from this do you anticipate? Personally, I see only upside. More flexibility — same mitigation of risk, same alignment of processes. We already have a number of changes in the pipeline, not least the new schedule in any form. How about we try that, along with a more modest proposal for bundled libs, and just _see how it feels_ before making any futher decisions. A “big bang” in process doesn’t need to be bigger — that only introduces more risk factors that will prevent us from evaluating the first changeset independently. Honestly, before making any further policy I’d just like to see if one or two releases can be done with the new schedule at all, at which point people will better be able to judge what the remaining pain points really are, instead of speculating about other future problems. —Gershom -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Mon Feb 19 08:51:15 2018 From: sylvain at haskus.fr (Sylvain Henry) Date: Mon, 19 Feb 2018 09:51:15 +0100 Subject: Help with build ordering issue Message-ID: <10096fd5-4240-d950-8c84-ccac1fd83252@haskus.fr> Hi, @Bodigrim is working on a patch (https://phabricator.haskell.org/D4212) to fix #14170. The build fails because of interface file errors: "bad interface file" for GHC.Natural and "failed to load interface" for GHC.Types. I suspect it is a wired-in module build ordering issue but I haven't been able to help fixing it. If anyone with more insights could help it would be much appreciated! Thanks, Sylvain From ben at well-typed.com Mon Feb 19 23:11:33 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 19 Feb 2018 18:11:33 -0500 Subject: [GHC DevOps Group] Release policies In-Reply-To: References: <0383353F-5894-4993-96E2-71EEE64E3CB5@justtesting.org> Message-ID: <87h8qcvalj.fsf@smart-cactus.org> Gershom B writes: > This proposal seems to have trailed off. I think it is worth putting a bow > on it and getting it signed off on for the GHC release policy page. > Yes, thanks for reviving this. I agree; we should wrap this up. > Let me restate it: > > > Bundled library maintainers agree to the following responsibilities: > > 1) When GHC cuts a feature-freeze branch, they too (if anything has > changed) cut a feature-freeze branch within two weeks at the maximum > (ideally sooner), to be included in the main GHC freeze branch. If > they do not do so, the last released version will be included instead. > This last sentence is a bit of an empty threat, I'm afraid. In most cases we sadly have little choice but to update all core libraries since they at very least need a bounds bump. In the case that *only* a bounds bump is needed I suppose we could push a Hackage revision. > 2) When GHC releases the first release candidate, maintainers (if > anything has changed) release new versions of their packages, to then > be depended on directly in the GHC repo. All submodules are then > replaced with their proper released versions for GHC release. > Yes, this sounds right to me. The only trouble that I can foresee is the difficulty of propagating the bounds down the core library dependency tree: Major bumps in packages like filepath tend to be rather painful as they require bumps in dependent libraries like directory, which in turn requires bumps in Cabal, etc. I suppose all we can really do is hope that upstreams are responsive enough to ensure that this whole process fits in the two-week window. This hasn't always been the case in the past, but perhaps having formal policies in place will help. If there is no objection from the devops group, I can send a message to the core library upstream maintainers describing the proposed policy. I've put up a brief description of the policy on the Wiki [1]. > > I know Chak and I had a back and forth, but I consider it resolved in the > direction of this proposal at this point, as a strict improvement over the > current situation that does not seem to invite further controversy. If in > the event of future things we learn, this proposal is inadequate, we can > revisit then. > > The one thing missing from both this proposal and the current release > policy page in general is discussion of the head overlay to hackage. I > think discussion of this should be integrated in both as a separate issue. > In particular — the feature freeze branches of bundled libraries can and > should be regularly updated in the head overlay. > Yes, I think the head.hackage issue is rather orthogonal to the matter of core library releases. It would make sense to mention it onn the releases page, but I personally don't feel as though I've had enough experience to distill a convenient work-flow using head.hackage, so I suspect there is more work to be done before this can be done. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/BootLibraries#Proposedreleasepolicy -------------- 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 well-typed.com Tue Feb 20 02:25:49 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 19 Feb 2018 21:25:49 -0500 Subject: Help with build ordering issue In-Reply-To: <10096fd5-4240-d950-8c84-ccac1fd83252@haskus.fr> References: <10096fd5-4240-d950-8c84-ccac1fd83252@haskus.fr> Message-ID: <87eflgv1ln.fsf@smart-cactus.org> Sylvain Henry writes: > Hi, > > @Bodigrim is working on a patch (https://phabricator.haskell.org/D4212) > to fix #14170. > > The build fails because of interface file errors: "bad interface file" > for GHC.Natural and "failed to load interface" for GHC.Types. > > I suspect it is a wired-in module build ordering issue but I haven't > been able to help fixing it. If anyone with more insights could help it > would be much appreciated! > Can you paste the full error? What module is failing to compile? Which definition is it loading the interface for? 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 Tue Feb 20 16:23:51 2018 From: sylvain at haskus.fr (Sylvain Henry) Date: Tue, 20 Feb 2018 17:23:51 +0100 Subject: Help with build ordering issue In-Reply-To: <87eflgv1ln.fsf@smart-cactus.org> References: <10096fd5-4240-d950-8c84-ccac1fd83252@haskus.fr> <87eflgv1ln.fsf@smart-cactus.org> Message-ID: <64559e0c-c5f1-b6f6-eb97-3c2387b30c39@haskus.fr> On 20/02/2018 03:25, Ben Gamari wrote: > Sylvain Henry writes: > >> Hi, >> >> @Bodigrim is working on a patch (https://phabricator.haskell.org/D4212) >> to fix #14170. >> >> The build fails because of interface file errors: "bad interface file" >> for GHC.Natural and "failed to load interface" for GHC.Types. >> >> I suspect it is a wired-in module build ordering issue but I haven't >> been able to help fixing it. If anyone with more insights could help it >> would be much appreciated! >> > Can you paste the full error? What module is failing to compile? Which > definition is it loading the interface for? > > Cheers, > > - Ben > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -this-unit-id base-4.11.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.2.0 -package-id integer-gmp-1.0.1.0 -this-unit-id base -XHaskell2010 -O -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/./GHC/Natural.hs -o libraries/base/dist-install/build/GHC/Natural.o -dyno libraries/base/dist-install/build/GHC/Natural.dyn_o :1:1: error: Bad interface file: libraries/base/dist-install/build/GHC/Natural.hi libraries/base/dist-install/build/GHC/Natural.hi: openBinaryFile: does not exist (No such file or directory) It fails in the CoreTidy pass. I also got this one (only after a make clean IIRC): libraries/base/GHC/Exception/Type.hs-boot:1:1: error: Failed to load interface for ‘GHC.Types’ There are files missing in the ‘ghc-prim-0.5.2.0’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. @hvr suggests it could could related to hs-boot files dependencies. Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Tue Feb 20 16:25:23 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 20 Feb 2018 19:25:23 +0300 Subject: A (late-)demand analysis and w/w question Message-ID: Hi, I was recently looking at #6087. One of the cases that increased allocations (see comment:27) is when we do worker/wrapper to pass an `Int#` instead of `Int` when we need the boxed form in the function body. This causes redundant allocations because we already have the boxed version of the value but we passed it unboxed as a result of worker/wrapper. This raises the obvious (but maybe naive?) question of whether we could improve the demand analysis and/or worker/wrapper to avoid unpacking arguments when the argument is boxed again somewhere in the function body. Does this make sense? Has anyone tried this before? Thanks, Ömer From simonpj at microsoft.com Tue Feb 20 22:47:18 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 20 Feb 2018 22:47:18 +0000 Subject: A (late-)demand analysis and w/w question In-Reply-To: References: Message-ID: It's called "reboxing" and is referred to in all the strictness analysis papers about GHC. I don't know a reliable way to get rid of it; but I have it paged out at the moment. Eg https://www.microsoft.com/en-us/research/publication/theory-practice-demand-analysis-haskell/ https://www.microsoft.com/en-us/research/publication/demand-analysis/ (the box-demad stuff in the appendix is not implemented in GHC) Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ömer | Sinan Agacan | Sent: 20 February 2018 16:25 | To: ghc-devs | Subject: A (late-)demand analysis and w/w question | | Hi, | | I was recently looking at #6087. One of the cases that increased | allocations (see comment:27) is when we do worker/wrapper to pass an | `Int#` instead of `Int` when we need the boxed form in the function body. | This causes redundant allocations because we already have the boxed | version of the value but we passed it unboxed as a result of | worker/wrapper. | | This raises the obvious (but maybe naive?) question of whether we could | improve the demand analysis and/or worker/wrapper to avoid unpacking | arguments when the argument is boxed again somewhere in the function | body. | | Does this make sense? Has anyone tried this before? | | Thanks, | | Ömer | _______________________________________________ | 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%7C6adfeaddd9964adcba3208d5787 | eb1b1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636547407938408171%7CU | nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | fQ%3D%3D%7C- | 1&sdata=XQ7xTxQepBeyi%2FDSHMmyXD0H8xFkh%2FoawqiIJJCUBYk%3D&reserved=0 From omeragacan at gmail.com Wed Feb 21 06:30:29 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 21 Feb 2018 09:30:29 +0300 Subject: A (late-)demand analysis and w/w question In-Reply-To: References: Message-ID: Thanks. I checked both papers, they mention that not all reboxing is eliminated, but as far as I can see they don't give an example reboxing that's not eliminated. It's not hard to come up with an example though. In this function fac :: Int -> Int fac 0 = 1 fac n = n * fac (n - 1) before simplification the worker looks like this Rec { -- RHS size: {terms: 29, types: 10, coercions: 0, joins: 0/2} $wfac__s28Z $wfac__s28Z = \ ww_s28U -> let { w_s28R w_s28R = I# ww_s28U } in case let { n_aU7 n_aU7 = w_s28R } in case check n_aU7 of { False -> case n_aU7 of { I# x_a27t -> case fac_ (I# (-# x_a27t 1#)) of { I# y_a27x -> I# (*# x_a27t y_a27x) } }; True -> n_aU7 } of ww_s28X { I# ww_s28Y -> ww_s28Y } `w_s28R` reboxes, but that's easily eliminated by the simplifier. In this example: {-# NOINLINE check #-} check :: Int -> Bool check !n = True fac_ :: Int -> Int fac_ n = if check n then n else n * fac_ (n - 1) even after simplifications we rebox the argument: Rec { -- RHS size: {terms: 17, types: 3, coercions: 0, joins: 0/0} $wfac_ $wfac_ = \ ww_s28U -> case check (I# ww_s28U) of { False -> case $wfac_ (-# ww_s28U 1#) of ww1_s28Y { __DEFAULT -> *# ww_s28U ww1_s28Y }; True -> ww_s28U } end Rec } This seems like a limitation of current demand analyser. I'm going to update the ticket and put it on hold for now. Ömer 2018-02-21 1:47 GMT+03:00 Simon Peyton Jones : > It's called "reboxing" and is referred to in all the strictness analysis papers about GHC. I don't know a reliable way to get rid of it; but I have it paged out at the moment. > > Eg https://www.microsoft.com/en-us/research/publication/theory-practice-demand-analysis-haskell/ > https://www.microsoft.com/en-us/research/publication/demand-analysis/ (the box-demad stuff in the appendix is not implemented in GHC) > > Simon > > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ömer > | Sinan Agacan > | Sent: 20 February 2018 16:25 > | To: ghc-devs > | Subject: A (late-)demand analysis and w/w question > | > | Hi, > | > | I was recently looking at #6087. One of the cases that increased > | allocations (see comment:27) is when we do worker/wrapper to pass an > | `Int#` instead of `Int` when we need the boxed form in the function body. > | This causes redundant allocations because we already have the boxed > | version of the value but we passed it unboxed as a result of > | worker/wrapper. > | > | This raises the obvious (but maybe naive?) question of whether we could > | improve the demand analysis and/or worker/wrapper to avoid unpacking > | arguments when the argument is boxed again somewhere in the function > | body. > | > | Does this make sense? Has anyone tried this before? > | > | Thanks, > | > | Ömer > | _______________________________________________ > | 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%7C6adfeaddd9964adcba3208d5787 > | eb1b1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636547407938408171%7CU > | nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi > | fQ%3D%3D%7C- > | 1&sdata=XQ7xTxQepBeyi%2FDSHMmyXD0H8xFkh%2FoawqiIJJCUBYk%3D&reserved=0 From simonpj at microsoft.com Wed Feb 21 09:45:34 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 21 Feb 2018 09:45:34 +0000 Subject: A (late-)demand analysis and w/w question In-Reply-To: References: Message-ID: Correct. Another example might be f 0 = [] f n = n : f (n-1) It's strict all right, but we need the boxed 'n' for the result. "Boxity" analysis might try to figure out when the boxed version is needed, and pass that too. At one stage I had that but it seemed unprincipled. Simo | -----Original Message----- | From: Ömer Sinan Ağacan [mailto:omeragacan at gmail.com] | Sent: 21 February 2018 06:30 | To: Simon Peyton Jones | Cc: ghc-devs | Subject: Re: A (late-)demand analysis and w/w question | | Thanks. I checked both papers, they mention that not all reboxing is | eliminated, but as far as I can see they don't give an example | reboxing that's not eliminated. It's not hard to come up with an | example though. In this function | | fac :: Int -> Int | fac 0 = 1 | fac n = n * fac (n - 1) | | before simplification the worker looks like this | | Rec { | -- RHS size: {terms: 29, types: 10, coercions: 0, joins: 0/2} | $wfac__s28Z | $wfac__s28Z | = \ ww_s28U -> | let { | w_s28R | w_s28R = I# ww_s28U } in | case let { | n_aU7 | n_aU7 = w_s28R } in | case check n_aU7 of { | False -> | case n_aU7 of { I# x_a27t -> | case fac_ (I# (-# x_a27t 1#)) of { I# y_a27x -> | I# (*# x_a27t y_a27x) | } | }; | True -> n_aU7 | } | of ww_s28X | { I# ww_s28Y -> | ww_s28Y | } | | `w_s28R` reboxes, but that's easily eliminated by the simplifier. In | this | example: | | {-# NOINLINE check #-} | check :: Int -> Bool | check !n = True | | fac_ :: Int -> Int | fac_ n = if check n then n else n * fac_ (n - 1) | | even after simplifications we rebox the argument: | | Rec { | -- RHS size: {terms: 17, types: 3, coercions: 0, joins: 0/0} | $wfac_ | $wfac_ | = \ ww_s28U -> | case check (I# ww_s28U) of { | False -> | case $wfac_ (-# ww_s28U 1#) of ww1_s28Y { __DEFAULT -> | *# ww_s28U ww1_s28Y | }; | True -> ww_s28U | } | end Rec } | | This seems like a limitation of current demand analyser. I'm going to | update the ticket and put it on hold for now. | | Ömer | | 2018-02-21 1:47 GMT+03:00 Simon Peyton Jones : | > It's called "reboxing" and is referred to in all the strictness | analysis papers about GHC. I don't know a reliable way to get rid of | it; but I have it paged out at the moment. | > | > Eg | > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.m | > icrosoft.com%2Fen-us%2Fresearch%2Fpublication%2Ftheory-practice- | demand | > -analysis- | haskell%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C6ad8305c | > | 795c4129a3f708d578f4b27d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C | > | 636547914720320997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo | > iV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C- | 1&sdata=LNLMS20hkf%2BP6yJSN3pH5Td | > AnZAU06Btx2RZKR8lBuo%3D&reserved=0 | > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.m | > icrosoft.com%2Fen-us%2Fresearch%2Fpublication%2Fdemand- | analysis%2F&dat | > | a=04%7C01%7Csimonpj%40microsoft.com%7C6ad8305c795c4129a3f708d578f4b27d | > | %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636547914720320997%7CUnk | > | nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw | > ifQ%3D%3D%7C- | 1&sdata=yTLi22Z3k1F%2F0CoqgOepxa6watIqpPMveAW%2B3vXLsNg%3 | > D&reserved=0 (the box-demad stuff in the appendix is not implemented | > in GHC) | > | > Simon | > | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | > | Ömer Sinan Agacan | > | Sent: 20 February 2018 16:25 | > | To: ghc-devs | > | Subject: A (late-)demand analysis and w/w question | > | | > | Hi, | > | | > | I was recently looking at #6087. One of the cases that increased | > | allocations (see comment:27) is when we do worker/wrapper to pass | an | > | `Int#` instead of `Int` when we need the boxed form in the | function body. | > | This causes redundant allocations because we already have the | boxed | > | version of the value but we passed it unboxed as a result of | > | worker/wrapper. | > | | > | This raises the obvious (but maybe naive?) question of whether we | > | could improve the demand analysis and/or worker/wrapper to avoid | > | unpacking arguments when the argument is boxed again somewhere in | > | the function body. | > | | > | Does this make sense? Has anyone tried this before? | > | | > | Thanks, | > | | > | Ömer | > | _______________________________________________ | > | 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%7C6adfeaddd9964adcba3208 | > | d5787 | > | | eb1b1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63654740793840817 | > | 1%7CU | > | | nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 | > | haWwi | > | fQ%3D%3D%7C- | > | | 1&sdata=XQ7xTxQepBeyi%2FDSHMmyXD0H8xFkh%2FoawqiIJJCUBYk%3D&reserved= | > | 0 From mail at nh2.me Thu Feb 22 21:52:20 2018 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Thu, 22 Feb 2018 22:52:20 +0100 Subject: DoAndIfThenElse In-Reply-To: References: Message-ID: <71b345e7-c0a5-5710-b28a-0bfc9766f8b5@nh2.me> I've filed https://ghc.haskell.org/trac/ghc/ticket/14842 for it. On 09/02/2018 10.24, Simon Peyton Jones via ghc-devs wrote: > At very least the extension should be documented! Would you like to open > a ticket for that?  And even offer a patch? From chris at crtimmonsinc.com Fri Feb 23 12:58:35 2018 From: chris at crtimmonsinc.com (Chris R. Timmons) Date: Fri, 23 Feb 2018 06:58:35 -0600 Subject: GNU make file in ghc/utils folder Message-ID: I'm trying to add a new utility to the $(TOP)/ghc/utils folder. The utility has a make file, but I can't seem to get it to play nice with GHC's build system.  The error I receive is "No rule to make target...". Here's a simple test environment that demonstrates the problem: --------------- 1. Create a new folder called $(TOP)/ghc/utils/testmake. 2. In the 'testmake' folder, create a file named "Makefile" with this content: dir = utils/testmake TOP = ../.. include $(TOP)/mk/sub-makefile.mk 3. In the 'testmake' folder, create a file named "ghc.mk" with this content (NOTE: My email app may have replaced the tab character before "@echo" with spaces.): $(eval $(call all-target,utils/testmake,utils/testmake/dummy_target)) utils/testmake/dummy_target:     @echo Hello world! ---------------- Running make results in a "No rule to make target" error: $ make make -C ../.. all_utils/testmake make[1]: Entering directory '/home/ctimmons/ghc' ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[2]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[2]: Nothing to be done for 'phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all_utils/testmake make[2]: *** No rule to make target 'all_utils/testmake'.  Stop. make[1]: *** [Makefile:127: all_utils/testmake] Error 2 make[1]: Leaving directory '/home/ctimmons/ghc' make: *** [../../mk/sub-makefile.mk:50: all] Error 2 However, running ghc.mk directly from the utils/testmake folder does not result in an error: $ make -C ../.. -f utils/testmake/ghc.mk make: Entering directory '/home/ctimmons/ghc' Hello world! make: Leaving directory '/home/ctimmons/ghc' What am I not understanding? Thanks. Chris From ben at smart-cactus.org Fri Feb 23 14:26:13 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 23 Feb 2018 09:26:13 -0500 Subject: GNU make file in ghc/utils folder In-Reply-To: References: Message-ID: <87d10vu6in.fsf@smart-cactus.org> "Chris R. Timmons" writes: > I'm trying to add a new utility to the $(TOP)/ghc/utils folder. The > utility has a make file, but I can't seem to get it to play nice with > GHC's build system.  The error I receive is "No rule to make target...". > > Here's a simple test environment that demonstrates the problem: > snip > > What am I not understanding? > I believe you need to add utils/testmake to the BUILD_SUBDIRS variable in the root ghc.mk. 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 chris at crtimmonsinc.com Fri Feb 23 19:18:59 2018 From: chris at crtimmonsinc.com (Chris R. Timmons) Date: Fri, 23 Feb 2018 13:18:59 -0600 Subject: GNU make file in ghc/utils folder In-Reply-To: <87d10vu6in.fsf@smart-cactus.org> References: <87d10vu6in.fsf@smart-cactus.org> Message-ID: On 2/23/2018 8:26 AM, Ben Gamari wrote: > "Chris R. Timmons" writes: > >> I'm trying to add a new utility to the $(TOP)/ghc/utils folder. The >> utility has a make file, but I can't seem to get it to play nice with >> GHC's build system.  The error I receive is "No rule to make target...". >> >> Here's a simple test environment that demonstrates the problem: >> > snip >> What am I not understanding? >> > I believe you need to add utils/testmake to the BUILD_SUBDIRS variable > in the root ghc.mk. > > Cheers, > > - Ben That did the trick. I somehow stumbled upon https://ghc.haskell.org/trac/ghc/wiki/Attic/Building/BuildSystem/New, and was using that as a guide.  It looks like I missed reading https://ghc.haskell.org/trac/ghc/wiki/Building/Modifying, where BUILD_DIRS is documented.  My bad. Thanks for the quick response. Chris. From ben at well-typed.com Sun Feb 25 17:42:15 2018 From: ben at well-typed.com (Ben Gamari) Date: Sun, 25 Feb 2018 12:42:15 -0500 Subject: [ANNOUNCE] GHC 8.4.1-rc1 available Message-ID: <87po4trmr3.fsf@smart-cactus.org> The GHC development team is pleased to announce the first (and likely final) release candidate of GHC 8.4.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-rc1 This release will likely be the last release before the final 8.4.1 release, which, if things go well, will be released one week from today. Due to user demand we now offer a binary distribution for 64-bit Fedora 27, which links against ncurses6. This is in contrast to the Debian 8 distribution, which links against ncurses5. Users of newer distributions (Fedora 27, Debian Sid) should use this new Fedora 27 distribution. Also due to user demand we have reintroduced compatibility with GCC 4.4, which earlier alphas had dropped due to #14244. Note that this release candidate is still affected by #14705, although this will certainly be resolved before the final release is made. === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes into users' hands and more quickly identify potential issues. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-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 ben at well-typed.com Sun Feb 25 19:57:58 2018 From: ben at well-typed.com (Ben Gamari) Date: Sun, 25 Feb 2018 14:57:58 -0500 Subject: [ANNOUNCE] GHC 8.4.1-rc1 available In-Reply-To: <87po4trmr3.fsf@smart-cactus.org> References: <87po4trmr3.fsf@smart-cactus.org> Message-ID: <87k1v0suyk.fsf@smart-cactus.org> Ben Gamari writes: > The GHC development team is pleased to announce the first (and likely > final) release candidate of GHC 8.4.1. The usual release artifacts are > available from > > https://downloads.haskell.org/~ghc/8.4.1-rc1 > > This release will likely be the last release before the final 8.4.1 > release, which, if things go well, will be released one week from today. > It has come to my attention that the fix for #14675 has broken `configure`'s `--disable-ld-override` flag. I have a fix [1] which will be applied to the final release. In the meantime, if you need to use this flag please define the `LD_NO_GOLD` environment variable to point to a non-gold linker when invoking `configure`. For instance, ./configure --disable-ld-override LD_NO_GOLD=ld.bfd Cheers, - Ben [1] https://phabricator.haskell.org/D4448 -------------- 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 well-typed.com Sun Feb 25 20:30:41 2018 From: ben at well-typed.com (Ben Gamari) Date: Sun, 25 Feb 2018 15:30:41 -0500 Subject: Help with build ordering issue In-Reply-To: <64559e0c-c5f1-b6f6-eb97-3c2387b30c39@haskus.fr> References: <10096fd5-4240-d950-8c84-ccac1fd83252@haskus.fr> <87eflgv1ln.fsf@smart-cactus.org> <64559e0c-c5f1-b6f6-eb97-3c2387b30c39@haskus.fr> Message-ID: <87h8q4stg4.fsf@smart-cactus.org> Sylvain Henry writes: > On 20/02/2018 03:25, Ben Gamari wrote: >> Sylvain Henry writes: >> >>> Hi, >>> >>> @Bodigrim is working on a patch (https://phabricator.haskell.org/D4212) >>> to fix #14170. >>> >>> The build fails because of interface file errors: "bad interface file" >>> for GHC.Natural and "failed to load interface" for GHC.Types. >>> >>> I suspect it is a wired-in module build ordering issue but I haven't >>> been able to help fixing it. If anyone with more insights could help it >>> would be much appreciated! >>> >> Can you paste the full error? What module is failing to compile? Which >> definition is it loading the interface for? >> >> Cheers, >> >> - Ben >> > > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -this-unit-id base-4.11.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.2.0 -package-id integer-gmp-1.0.1.0 -this-unit-id base -XHaskell2010 -O -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/./GHC/Natural.hs -o libraries/base/dist-install/build/GHC/Natural.o -dyno libraries/base/dist-install/build/GHC/Natural.dyn_o > > :1:1: error: > Bad interface file: libraries/base/dist-install/build/GHC/Natural.hi > libraries/base/dist-install/build/GHC/Natural.hi: openBinaryFile: does not exist (No such file or directory) > Hmm, I'm afraid that's not particularly illuminating. It would be helpful to see the output from -ddump-if-trace as this will tell you why GHC is trying to load this interface file. 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 Feb 26 09:55:44 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Feb 2018 09:55:44 +0000 Subject: [commit: ghc] master: testsuite: Bump allocations for T9630 (f57c305) In-Reply-To: <20180225215739.916993A5F6@ghc.haskell.org> References: <20180225215739.916993A5F6@ghc.haskell.org> Message-ID: This is a reduction => good! "Bump" is usually bad. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf | Of git at git.haskell.org | Sent: 25 February 2018 21:58 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: testsuite: Bump allocations for T9630 | (f57c305) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha | skell.org%2Ftrac%2Fghc%2Fchangeset%2Ff57c3059d7c8b8e00bd3a9f9153c3520f | 6db14d4%2Fghc&data=04%7C01%7Csimonpj%40microsoft.com%7Cbff75d8952bc489 | 7f12608d57c9ae8c0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365519 | 27127060212%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwifQ%3D%3D%7C- | 1&sdata=Hk8Q%2FVgrwqEUkysgX3Stj5GO5t3YNeM04wALzV6ZZSE%3D&reserved=0 | | >--------------------------------------------------------------- | | commit f57c3059d7c8b8e00bd3a9f9153c3520f6db14d4 | Author: Ben Gamari | Date: Sun Feb 25 16:23:39 2018 -0500 | | testsuite: Bump allocations for T9630 | | | >--------------------------------------------------------------- | | f57c3059d7c8b8e00bd3a9f9153c3520f6db14d4 | testsuite/tests/perf/compiler/all.T | 3 ++- | 1 file changed, 2 insertions(+), 1 deletion(-) | | diff --git a/testsuite/tests/perf/compiler/all.T | b/testsuite/tests/perf/compiler/all.T | index 1ae69e7..1a2413a 100644 | --- a/testsuite/tests/perf/compiler/all.T | +++ b/testsuite/tests/perf/compiler/all.T | @@ -1228,9 +1228,10 @@ test ('T9630', | [ compiler_stats_num_field('max_bytes_used', # Note [residency] | [(platform('x86_64-unknown-mingw32'), 39867088, 15), | # 2017-12-24: 34171816 (x64/Windows) | - (wordsize(64), 41568168, 15) | + (wordsize(64), 35324712, 15) | # initial: 56955240 | # 2017-06-07: 41568168 Stop the specialiser generating | loopy code | + # 2018-02-25: 35324712 It's not entirely clear | ]), | extra_clean(['T9630a.hi', 'T9630a.o']) | ], | | _______________________________________________ | 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%7Cbff75d8952bc4897f1260 | 8d57c9ae8c0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365519271270 | 60212%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB | TiI6Ik1haWwifQ%3D%3D%7C- | 1&sdata=2bTG4reUJV7m3RsSUMse20LChfZPcJP3Ea%2FQkgqmLFw%3D&reserved=0 From tab at snarc.org Mon Feb 26 15:02:07 2018 From: tab at snarc.org (Vincent Hanquez) Date: Mon, 26 Feb 2018 15:02:07 +0000 Subject: [ANNOUNCE] GHC 8.4.1-rc1 available In-Reply-To: <87po4trmr3.fsf@smart-cactus.org> References: <87po4trmr3.fsf@smart-cactus.org> Message-ID: <881c4581-eaae-009a-626b-024f29d0a010@snarc.org> On 25/02/18 17:42, Ben Gamari wrote: > The GHC development team is pleased to announce the first (and likely > final) release candidate of GHC 8.4.1. The usual release artifacts are > available from > > https://downloads.haskell.org/~ghc/8.4.1-rc1 > Hi Ben, Looks like both SHA1SUM and SHA256SUM are missing the fedora27 variant Cheers, Vincent From ben at smart-cactus.org Mon Feb 26 15:57:17 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 26 Feb 2018 10:57:17 -0500 Subject: [commit: ghc] master: testsuite: Bump allocations for T9630 (f57c305) In-Reply-To: References: <20180225215739.916993A5F6@ghc.haskell.org> Message-ID: <87d10rsq07.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > This is a reduction => good! > > "Bump" is usually bad. > Mmm, fair point. I'll use a more precise wording in the future. 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 well-typed.com Mon Feb 26 16:01:59 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 26 Feb 2018 11:01:59 -0500 Subject: [ANNOUNCE] GHC 8.4.1-rc1 available In-Reply-To: <881c4581-eaae-009a-626b-024f29d0a010@snarc.org> References: <87po4trmr3.fsf@smart-cactus.org> <881c4581-eaae-009a-626b-024f29d0a010@snarc.org> Message-ID: <87a7vvspsc.fsf@smart-cactus.org> Vincent Hanquez writes: > On 25/02/18 17:42, Ben Gamari wrote: >> The GHC development team is pleased to announce the first (and likely >> final) release candidate of GHC 8.4.1. The usual release artifacts are >> available from >> >> https://downloads.haskell.org/~ghc/8.4.1-rc1 >> > Hi Ben, > > Looks like both SHA1SUM and SHA256SUM are missing the fedora27 variant > Good catch; it looks like I neglected to regenerate them after fixing the name of the the Fedora vairant. Fixed. 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 Mon Feb 26 16:37:02 2018 From: sylvain at haskus.fr (Sylvain Henry) Date: Mon, 26 Feb 2018 17:37:02 +0100 Subject: Help with build ordering issue In-Reply-To: <87h8q4stg4.fsf@smart-cactus.org> References: <10096fd5-4240-d950-8c84-ccac1fd83252@haskus.fr> <87eflgv1ln.fsf@smart-cactus.org> <64559e0c-c5f1-b6f6-eb97-3c2387b30c39@haskus.fr> <87h8q4stg4.fsf@smart-cactus.org> Message-ID: <736a4309-b95e-c12a-200b-41a9dbb66d06@haskus.fr> On 25/02/2018 21:30, Ben Gamari wrote: > Hmm, I'm afraid that's not particularly illuminating. > > It would be helpful to see the output from -ddump-if-trace as this will > tell you why GHC is trying to load this interface file. Thanks, it has been helpful. The relevant trace is: Need decl for mkNatural Considering whether to load GHC.Natural {- SYSTEM -} Reading interface for base-4.11.0.0:GHC.Natural;     reason: Need decl for mkNatural readIFace libraries/base/dist-install/build/GHC/Natural.hi Now I still don't know why GHC is trying to load the interface of the module it is compiling. From a.pelenitsyn at gmail.com Mon Feb 26 17:04:36 2018 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Mon, 26 Feb 2018 17:04:36 +0000 Subject: Guarded Impredicativity implementation Message-ID: Dear ghc-devs, Is there any work has been done on the latest (ttbomk) proposal for impredicative types in Haskell: > Guarded impredicative polymorphism by Alejandro Serrano, Jurriaan Hage, Dimitrios Vytiniotis, Simon Peyton Jones https://www.microsoft.com/en-us/research/wp-content/uploads/2017/07/impredicative-Jul17.pdf Or are there any plans to do so? I wasn't able to spot any mentions of this in either of GHC's forums (this list, Trac, wiki, ghc-proposals repo). -- Best wishes, Artem Pelenitsyn -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Feb 26 18:19:54 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 26 Feb 2018 13:19:54 -0500 Subject: Help with build ordering issue In-Reply-To: <736a4309-b95e-c12a-200b-41a9dbb66d06@haskus.fr> References: <10096fd5-4240-d950-8c84-ccac1fd83252@haskus.fr> <87eflgv1ln.fsf@smart-cactus.org> <64559e0c-c5f1-b6f6-eb97-3c2387b30c39@haskus.fr> <87h8q4stg4.fsf@smart-cactus.org> <736a4309-b95e-c12a-200b-41a9dbb66d06@haskus.fr> Message-ID: <87vaejr4u2.fsf@smart-cactus.org> Sylvain Henry writes: > On 25/02/2018 21:30, Ben Gamari wrote: >> Hmm, I'm afraid that's not particularly illuminating. >> >> It would be helpful to see the output from -ddump-if-trace as this will >> tell you why GHC is trying to load this interface file. > > Thanks, it has been helpful. The relevant trace is: > > Need decl for mkNatural > Considering whether to load GHC.Natural {- SYSTEM -} > Reading interface for base-4.11.0.0:GHC.Natural; >     reason: Need decl for mkNatural > readIFace libraries/base/dist-install/build/GHC/Natural.hi > > Now I still don't know why GHC is trying to load the interface of the > module it is compiling. Keep in mind that GHC may call upon mkNatural while typechecking even without an import as it is known-key. The output of -ddump-tc-trace might also help identify whether this is the case. I would help if there were some way I could reproduce this. 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 Mon Feb 26 19:11:07 2018 From: sylvain at haskus.fr (Sylvain Henry) Date: Mon, 26 Feb 2018 20:11:07 +0100 Subject: Help with build ordering issue In-Reply-To: <87vaejr4u2.fsf@smart-cactus.org> References: <10096fd5-4240-d950-8c84-ccac1fd83252@haskus.fr> <87eflgv1ln.fsf@smart-cactus.org> <64559e0c-c5f1-b6f6-eb97-3c2387b30c39@haskus.fr> <87h8q4stg4.fsf@smart-cactus.org> <736a4309-b95e-c12a-200b-41a9dbb66d06@haskus.fr> <87vaejr4u2.fsf@smart-cactus.org> Message-ID: On 26/02/2018 19:19, Ben Gamari wrote: > Sylvain Henry writes: > >> On 25/02/2018 21:30, Ben Gamari wrote: >>> Hmm, I'm afraid that's not particularly illuminating. >>> >>> It would be helpful to see the output from -ddump-if-trace as this will >>> tell you why GHC is trying to load this interface file. >> Thanks, it has been helpful. The relevant trace is: >> >> Need decl for mkNatural >> Considering whether to load GHC.Natural {- SYSTEM -} >> Reading interface for base-4.11.0.0:GHC.Natural; >>     reason: Need decl for mkNatural >> readIFace libraries/base/dist-install/build/GHC/Natural.hi >> >> Now I still don't know why GHC is trying to load the interface of the >> module it is compiling. > Keep in mind that GHC may call upon mkNatural while typechecking even > without an import as it is known-key. The output of -ddump-tc-trace > might also help identify whether this is the case. It must be something like this because I get the same error even when I reduce GHC.Natural module to: {-# LANGUAGE NoImplicitPrelude #-} module GHC.Natural where > > I would help if there were some way I could reproduce this. The failing patch is here: https://phabricator.haskell.org/D4212 Let's continue the discussion there to avoid spamming this list ;) Thanks, Sylvain From simonpj at microsoft.com Mon Feb 26 22:36:31 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Feb 2018 22:36:31 +0000 Subject: Guarded Impredicativity implementation In-Reply-To: References: Message-ID: Alejandro may want to comment… From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Artem Pelenitsyn Sent: 26 February 2018 17:05 To: ghc-devs at haskell.org Subject: Guarded Impredicativity implementation Dear ghc-devs, Is there any work has been done on the latest (ttbomk) proposal for impredicative types in Haskell: > Guarded impredicative polymorphism by Alejandro Serrano, Jurriaan Hage, Dimitrios Vytiniotis, Simon Peyton Jones https://www.microsoft.com/en-us/research/wp-content/uploads/2017/07/impredicative-Jul17.pdf Or are there any plans to do so? I wasn't able to spot any mentions of this in either of GHC's forums (this list, Trac, wiki, ghc-proposals repo). -- Best wishes, Artem Pelenitsyn -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Tue Feb 27 09:59:27 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 27 Feb 2018 09:59:27 +0000 Subject: An idea for a different style of metaprogramming evaluation using the optimiser Message-ID: I've had an idea for a while of a different way we could evaluate TH-like splices which would be more lightweight and easier to work with. The idea is to create a third quotation/splicing mechanism which has no introspection (like MetaML) but then to evaluate these quotes and splices in the optimiser rather than using the bytecode interpreter. I am motivated by the many examples of recursive functions in libraries, which when given a statically known argument should be able to be unrolled to produce much better code. It is understandable that the compiler doesn't try to do this itself but there should be an easy way for the user to direct the compiler to do so. (See also https://www.reddit.com/r/haskell/comments/7yvb43/ghc_compiletime_evaluation/) An example to be concrete: Take the power function such that power k n computes k^n. power :: Int -> Int -> Int power k n = if n == 0 then 1 else k * power k (n - 1) If we statically know n then we can create a staged version. We use R to indicate that an argument is dynamically known. power :: R Int -> Int -> R Int power k n = if n == 0 then .< 1 >. else .< ~k * ~(power k (n-1)) >. One way to implement this in Haskell is to use typed template haskell quoting and splicing. The key thing to notice about why this works is that in order to splice `power k (n-1)` we need to evaluate `power k (n-1)` so that we have something of type `R Int` which we can then splice back into the quote. The way this is currently implemented is that the bytecode interpreter runs these splices in order to find out what they evaluate to. The idea is that instead, we add another mode which runs splices in the core-to-core optimiser. The optimiser performs evaluation by beta reduction, inlining and constant folding. For simple definitions on algebraic data types it does a very good job of eliminating overhead. As long as the call is not recursive. If we can just get the optimiser to inline recursive calls in a controlled manner as well, it should do a good job on the unrolled definition. The benefits of this are that it works across all platforms and fits nicely already into the compilation pipeline. It also fits in nicely with the intuition that a "quote" means to stop evaluating and a "splice" means to evaluate. A disadvantage is that the optimiser is only a *partial* evaluator rather than an evaluator. It gets stuck evaluating things containing primitives and so on. I don't forsee this as a major issue but a limitation that library authors should be aware of when writing their staged programs. To go back to the power example, the recursive condition would have to be an inductively defined natural (data N = Z | S N) rather than an Int as the comparison operator for integers can't be evaluated by the optimiser. It is already rather easy to write staged programs which loop if you don't carefully consider the staging so this seems now worse than the status quo. Does this sound at all sensible to anyone else? Matt From mail at joachim-breitner.de Tue Feb 27 17:01:57 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 27 Feb 2018 12:01:57 -0500 Subject: An idea for a different style of metaprogramming evaluation using the optimiser In-Reply-To: References: Message-ID: <1519750917.1113.45.camel@joachim-breitner.de> Hi, something like this would be great. I don’t have a sense yet of what “something” should be like. Am Dienstag, den 27.02.2018, 09:59 +0000 schrieb Matthew Pickering: > To go back to the power example, the recursive > condition would have to be an inductively defined natural (data N = Z > | S N) rather than an Int as the comparison operator for integers > can't be evaluated by the optimiser. Sure they can: $ cat ConstantFolding.hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -fplugin=Test.Inspection.Plugin #-} module ConstantFolding where import Test.Inspection ltInt :: Bool ltInt = (3::Int) > 2 ltInteger :: Bool ltInteger = (3::Integer) > 2 true :: Bool true = True inspect $ 'ltInt === 'true inspect $ 'ltInteger === 'true $ ghc -O ConstantFolding.hs [1 of 1] Compiling ConstantFolding ( ConstantFolding.hs, ConstantFolding.o ) ConstantFolding.hs:17:1: ltInt === true passed. ConstantFolding.hs:18:1: ltInteger === true passed. inspection testing successful expected successes: 2 As an alternative with a maybe simpler user interface (and probably less power), I wonder if we can create a magic function > compileTimeWHNF :: a -> a or > compileTimeNF :: a -> a and a GHC core plugin (or eventually built-in thing) that finds these magic functions and evaluates their arguments, using the simplifier. Cheers, 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 sgraf1337 at gmail.com Tue Feb 27 18:35:18 2018 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Tue, 27 Feb 2018 19:35:18 +0100 Subject: An idea for a different style of metaprogramming evaluation using the optimiser In-Reply-To: <1519750917.1113.45.camel@joachim-breitner.de> References: <1519750917.1113.45.camel@joachim-breitner.de> Message-ID: Hey Matt, cool idea! Also it looks like such a tool could 'solve' stream fusion: https://ghc.haskell.org/trac/ghc/ticket/915#comment:52 Greetings Sebastian 2018-02-27 18:01 GMT+01:00 Joachim Breitner : > Hi, > > something like this would be great. I don’t have a sense yet of what > “something” should be like. > > > Am Dienstag, den 27.02.2018, 09:59 +0000 schrieb Matthew Pickering: > > To go back to the power example, the recursive > > condition would have to be an inductively defined natural (data N = Z > > | S N) rather than an Int as the comparison operator for integers > > can't be evaluated by the optimiser. > > Sure they can: > > $ cat ConstantFolding.hs > {-# LANGUAGE TemplateHaskell #-} > {-# OPTIONS_GHC -fplugin=Test.Inspection.Plugin #-} > module ConstantFolding where > > import Test.Inspection > > ltInt :: Bool > ltInt = (3::Int) > 2 > > ltInteger :: Bool > ltInteger = (3::Integer) > 2 > > true :: Bool > true = True > > > inspect $ 'ltInt === 'true > inspect $ 'ltInteger === 'true > > $ ghc -O ConstantFolding.hs > [1 of 1] Compiling ConstantFolding ( ConstantFolding.hs, > ConstantFolding.o ) > ConstantFolding.hs:17:1: ltInt === true passed. > ConstantFolding.hs:18:1: ltInteger === true passed. > inspection testing successful > expected successes: 2 > > > > As an alternative with a maybe simpler user interface (and probably > less power), I wonder if we can create a magic function > > compileTimeWHNF :: a -> a > or > > compileTimeNF :: a -> a > and a GHC core plugin (or eventually built-in thing) that finds these > magic functions and evaluates their arguments, using the simplifier. > > > Cheers, > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Wed Feb 28 07:37:13 2018 From: juhpetersen at gmail.com (Jens Petersen) Date: Wed, 28 Feb 2018 16:37:13 +0900 Subject: [ANNOUNCE] GHC 8.4.1-rc1 available In-Reply-To: <87po4trmr3.fsf@smart-cactus.org> References: <87po4trmr3.fsf@smart-cactus.org> Message-ID: On 26 February 2018 at 02:42, Ben Gamari wrote: > https://downloads.haskell.org/~ghc/8.4.1-rc1 I'd like to ask: what BuildFlavour are these builds? Perf or something else? Is there a build.mk file for them? (If so would it make sense to include it in the binary tarballs?) I started https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.4.1/ for Fedora testing. Thanks, Jens From matthewtpickering at gmail.com Wed Feb 28 11:26:35 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 28 Feb 2018 11:26:35 +0000 Subject: An idea for a different style of metaprogramming evaluation using the optimiser In-Reply-To: <1519750917.1113.45.camel@joachim-breitner.de> References: <1519750917.1113.45.camel@joachim-breitner.de> Message-ID: You have identified a small inaccuracy in my original email. It is true that ultimately 3 == 0 will be evaluated but these constant folding opportunities are only applied later after other inlining takes place. It becomes quite crucial under this scheme when different optimisations happen because when we inline a recursive function, we have to make sure to apply the right evaluation steps before trying to simplify the function body. In my hacked together implementation of this, constant folding happens too late so only the algebraic version teminated. Cheers, Matt On Tue, Feb 27, 2018 at 5:01 PM, Joachim Breitner wrote: > Hi, > > something like this would be great. I don’t have a sense yet of what > “something” should be like. > > > Am Dienstag, den 27.02.2018, 09:59 +0000 schrieb Matthew Pickering: >> To go back to the power example, the recursive >> condition would have to be an inductively defined natural (data N = Z >> | S N) rather than an Int as the comparison operator for integers >> can't be evaluated by the optimiser. > > Sure they can: > > $ cat ConstantFolding.hs > {-# LANGUAGE TemplateHaskell #-} > {-# OPTIONS_GHC -fplugin=Test.Inspection.Plugin #-} > module ConstantFolding where > > import Test.Inspection > > ltInt :: Bool > ltInt = (3::Int) > 2 > > ltInteger :: Bool > ltInteger = (3::Integer) > 2 > > true :: Bool > true = True > > > inspect $ 'ltInt === 'true > inspect $ 'ltInteger === 'true > > $ ghc -O ConstantFolding.hs > [1 of 1] Compiling ConstantFolding ( ConstantFolding.hs, > ConstantFolding.o ) > ConstantFolding.hs:17:1: ltInt === true passed. > ConstantFolding.hs:18:1: ltInteger === true passed. > inspection testing successful > expected successes: 2 > > > > As an alternative with a maybe simpler user interface (and probably > less power), I wonder if we can create a magic function >> compileTimeWHNF :: a -> a > or >> compileTimeNF :: a -> a > and a GHC core plugin (or eventually built-in thing) that finds these > magic functions and evaluates their arguments, using the simplifier. > > > Cheers, > Joachim > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ From mail at joachim-breitner.de Wed Feb 28 13:22:38 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 28 Feb 2018 08:22:38 -0500 Subject: An idea for a different style of metaprogramming evaluation using the optimiser In-Reply-To: References: <1519750917.1113.45.camel@joachim-breitner.de> Message-ID: <39DAC0D8-FF46-490F-BB3E-8DA6F1C5D60C@joachim-breitner.de> > In my hacked together implementation of this, constant folding happens too late so only the algebraic version teminated. ah, very good point! Joachim Am 28. Februar 2018 06:26:35 EST schrieb Matthew Pickering : >You have identified a small inaccuracy in my original email. > >It is true that ultimately 3 == 0 will be evaluated but these constant >folding opportunities are only applied later after other inlining >takes place. > >It becomes quite crucial under this scheme when different >optimisations happen because when we inline a recursive function, we >have to make sure to apply the right evaluation steps before trying to >simplify the function body. >In my hacked together implementation of this, constant folding happens >too late so only the algebraic version teminated. > >Cheers, > >Matt > >On Tue, Feb 27, 2018 at 5:01 PM, Joachim Breitner > wrote: >> Hi, >> >> something like this would be great. I don’t have a sense yet of what >> “something” should be like. >> >> >> Am Dienstag, den 27.02.2018, 09:59 +0000 schrieb Matthew Pickering: >>> To go back to the power example, the recursive >>> condition would have to be an inductively defined natural (data N = >Z >>> | S N) rather than an Int as the comparison operator for integers >>> can't be evaluated by the optimiser. >> >> Sure they can: >> >> $ cat ConstantFolding.hs >> {-# LANGUAGE TemplateHaskell #-} >> {-# OPTIONS_GHC -fplugin=Test.Inspection.Plugin #-} >> module ConstantFolding where >> >> import Test.Inspection >> >> ltInt :: Bool >> ltInt = (3::Int) > 2 >> >> ltInteger :: Bool >> ltInteger = (3::Integer) > 2 >> >> true :: Bool >> true = True >> >> >> inspect $ 'ltInt === 'true >> inspect $ 'ltInteger === 'true >> >> $ ghc -O ConstantFolding.hs >> [1 of 1] Compiling ConstantFolding ( ConstantFolding.hs, >> ConstantFolding.o ) >> ConstantFolding.hs:17:1: ltInt === true passed. >> ConstantFolding.hs:18:1: ltInteger === true passed. >> inspection testing successful >> expected successes: 2 >> >> >> >> As an alternative with a maybe simpler user interface (and probably >> less power), I wonder if we can create a magic function >>> compileTimeWHNF :: a -> a >> or >>> compileTimeNF :: a -> a >> and a GHC core plugin (or eventually built-in thing) that finds these >> magic functions and evaluates their arguments, using the simplifier. >> >> >> Cheers, >> Joachim >> >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ From ben at well-typed.com Wed Feb 28 15:15:54 2018 From: ben at well-typed.com (Ben Gamari) Date: Wed, 28 Feb 2018 10:15:54 -0500 Subject: [ANNOUNCE] GHC 8.4.1-rc1 available In-Reply-To: References: <87po4trmr3.fsf@smart-cactus.org> Message-ID: <87muztqh5m.fsf@smart-cactus.org> Jens Petersen writes: > On 26 February 2018 at 02:42, Ben Gamari wrote: >> https://downloads.haskell.org/~ghc/8.4.1-rc1 > > I'd like to ask: what BuildFlavour are these builds? Perf or something else? > Is there a build.mk file for them? (If so would it make sense to > include it in the binary tarballs?) > > > I started https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.4.1/ > for Fedora testing. > All of the binary distributions since 7.10.3 have been produced using this script [1]. It uses `BuildFlavour=` which is essentially equivalent to `BuildFlavour=perf`. Cheers, - Ben [1] https://github.com/bgamari/ghc-utils/blob/master/rel-eng/bin-release.sh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: