From ben at smart-cactus.org Wed Feb 1 00:09:50 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 31 Jan 2017 19:09:50 -0500 Subject: Join points revised In-Reply-To: <2ce83529-5c80-ffe8-9b6f-76fad0070ef9@cs.uoregon.edu> References: <2ce83529-5c80-ffe8-9b6f-76fad0070ef9@cs.uoregon.edu> Message-ID: <87tw8ekbzl.fsf@ben-laptop.smart-cactus.org> Luke Maurer writes: > Revised version of the join points patch is up: > > https://phabricator.haskell.org/D2853 > > Hoping to commit ASAP. Thanks all! > I have a few further review comments that I'm about to submit. 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 rae at cs.brynmawr.edu Wed Feb 1 01:19:08 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 31 Jan 2017 20:19:08 -0500 Subject: D2038: [WIP] TysPrim: Generalize kind of (->) In-Reply-To: <50EB9209-1A0F-4DA8-BA06-586DFD3C68DE@cs.brynmawr.edu> References: <20170131125046.126142.13535.3FCE5C50@phabricator.haskell.org> <50EB9209-1A0F-4DA8-BA06-586DFD3C68DE@cs.brynmawr.edu> Message-ID: <9CF741E7-5985-4267-8ECA-5E5E7E870F57@cs.brynmawr.edu> I had another thought on my drive home: why do we need to sort out Constraint v Type for 8.2? I have the patch, and it's essentially all set. But it weakens equality in a way that's troublesome for D2038 and introduces heterogeneous axioms, which are strange, ill-understood beasts. And I don't think we need it. On the other hand, D2038 is essential for the new Typeable, because it's the only way we can give (->) a proper kind. So, I propose: 1. Hold off on Constraint v Type until after the branch is cut. 2. Do what we can to mitigate Constraint v Type confusion vis-a-vis Typeable. (For example, make sure that there aren't Typeable instances for both, and have TcTypeable provide the Type instance whenever the Constraint instance is requested.) 3. Advertise that GHC will be a little confused on this point, and that, as far as Typeable is concerned, Constraint and Type are synonymous. 4. On the Constraint v Type patch, restore the full power of KindCo. This makes the type system broken, but I don't think the sky will come crashing down. 5. Merge Constraint v Type after the branch is cut. This will make GHC HEAD unsound in a new way, but no one will notice unless they try. 6. File a priority-highest bug to eliminate newtype-classes (which beget heterogeneous axioms in the Constraint/=Type world). 7. Finish the first-class reification design and implement before 8.4. 8. Remove newtype-classes, thus eliminating heterogeneous axioms and the unsoundness mentioned in (5). This route seems, to me, far preferable to monkeying around with roles and such in ways that we have no assurances are sound. (Remember, roles are there to keep the type system safe and sound. They were not added simply to annoy everyone, though they accomplish that goal quite nicely.) What do we think? It's not ideal, but I think it's the best of suboptimal alternatives. And it's no worse than 8.0 w.r.t. Constraint v Type. Richard > On Jan 31, 2017, at 5:56 PM, Richard Eisenberg wrote: > >> >> On Jan 31, 2017, at 5:41 PM, Simon Peyton Jones > wrote: >> >> But that can only happen if `(->)` has suitable roles. >> What if it doesn’t? > > The “correct” roles for (->) of the kind you gave is `nominal nominal nominal nominal representational representational`. That is, the dependent arguments are nominal, and the others are representational. This is because all kind-level coercions are nominal. You seem to be suggesting giving (->) different roles. I honestly don’t know what that would mean -- normally, GHC prevents you from specifying a weaker role than it would infer. It smells pretty foul to me, but I can’t quite put my finger on what would go wrong at the moment. > >> >> What if we just had an axiom >> >> axArrow v :: (->) Vanilla v >> ~R (->) Constraint v > > I think we’d also need one for results... but maybe not. > >> >> or something like that. Then we get >> >> [W] g : (->) Vanilla Vanilla Ptr Ptr (C a) Int >> ~R (->) Constraint Vanilla Ptr Ptr a Int >> >> We decompose partly and solve thus >> >> g = (axArrow Vanilla) axC > > And this works only if we weaken (->)’s roles. > > This whole road just feels like the wrong way, as soon as we started contemplating a heterogeneous axiom, which are ruled out in the literature, even when we have kind equalities. > > I think the Right Answer is to get rid of newtype-classes & fix reify, and I’m worried that anything short of that will fail catastrophically at some point. Otherwise, it’s patches on top of patches. > > I don’t think there is disagreement here, but there is the question about what to do for 8.2.... and unless we’re ready to roll out the new reify, I think the best course of action is to delay the new Typeable and all this Constraint v Type stuff until 8.4. (The new levity polymorphism stuff already committed is hunky-dory.) > > Richard > >> >> >> Simon >> <> >> From: noreply at phabricator.haskell.org [mailto:noreply at phabricator.haskell.org ] >> Sent: 31 January 2017 12:51 >> To: Simon Peyton Jones > >> Subject: [Differential] [Commented On] D2038: [WIP] TysPrim: Generalize kind of (->) >> >> goldfire added a comment. >> >> View Revision >> >> >> In D2038#89360 , @simonpj wrote: >> >> To avoid being able to extract ContraintRep ~R LiftedPtrRep we decided to weaken one of the coercion constructors, the one that gets a kind coercion from a type coercion. We don't need it, and it's awkward here. >> >> The problem is that we need it with this patch. I was able to weaken this coercion constructor (KindCo) in my patchD3023 , but this patch uses it in a fundamental way that we can't get around. To wit: >> >> class C a where >> meth :: a >> >> axC :: (C a :: Constraint) ~R (a :: Type) >> Now, we wish to cast C a -> a to a -> a.. This cast will look like (->) ?? axC . What goes in the??? It's got to be something involving KindCo axC, which is disallowed as per our earlier decision. Therein lies the problem. >> >> As for reify: Yes, I'm agreed with that email. But is that implemented yet? Is a design settled on? I don't see a ghc-proposal. Are we wiling to take a dependency on that work in order to get this done? >> >> To be clear, my chief worry isn't that these problems cannot be solved by any means -- I'm just worried about the timing of this all and our desire to get 8.2 out the door. >> >> >> REPOSITORY >> rGHC Glasgow Haskell Compiler >> >> REVISION DETAIL >> https://phabricator.haskell.org/D2038 >> >> EMAIL PREFERENCES >> https://phabricator.haskell.org/settings/panel/emailpreferences/ >> >> To: bgamari, goldfire, austin >> Cc: simonpj, RyanGlScott, thomie > > _______________________________________________ > 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 Wed Feb 1 01:56:10 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 31 Jan 2017 20:56:10 -0500 Subject: D2038: [WIP] TysPrim: Generalize kind of (->) In-Reply-To: <9CF741E7-5985-4267-8ECA-5E5E7E870F57@cs.brynmawr.edu> References: <20170131125046.126142.13535.3FCE5C50@phabricator.haskell.org> <50EB9209-1A0F-4DA8-BA06-586DFD3C68DE@cs.brynmawr.edu> <9CF741E7-5985-4267-8ECA-5E5E7E870F57@cs.brynmawr.edu> Message-ID: <87o9ymk72d.fsf@ben-laptop.smart-cactus.org> Richard Eisenberg writes: > I had another thought on my drive home: why do we need to sort out > Constraint v Type for 8.2? I have the patch, and it's essentially all > set. But it weakens equality in a way that's troublesome for D2038 and > introduces heterogeneous axioms, which are strange, ill-understood > beasts. And I don't think we need it. > > On the other hand, D2038 is essential for the new Typeable, because > it's the only way we can give (->) a proper kind. > Snipped well-considered plan for proceeding. > This route seems, to me, far preferable to monkeying around with roles > and such in ways that we have no assurances are sound. (Remember, > roles are there to keep the type system safe and sound. They were not > added simply to annoy everyone, though they accomplish that goal quite > nicely.) > :) > What do we think? It's not ideal, but I think it's the best of > suboptimal alternatives. And it's no worse than 8.0 w.r.t. Constraint > v Type. > This sounds quite reasonable to me. I will need to fix up the remaining issues in D2038 surrounding Constraint, but I think this shouldn't be so difficult. The only reason I haven't tried already was my belief that Constraint/Type would be resolved soon. I'll try to push another version of D2038 tonight. 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 Wed Feb 1 08:31:06 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 1 Feb 2017 08:31:06 +0000 Subject: Join points revised In-Reply-To: <2ce83529-5c80-ffe8-9b6f-76fad0070ef9@cs.uoregon.edu> References: <2ce83529-5c80-ffe8-9b6f-76fad0070ef9@cs.uoregon.edu> Message-ID: GHC devs: this join-point patch has been long in gestation, and I've reviewed it several times with Luke. I think it's ready to go, but if you have time to take a look, please do. The Wiki page https://ghc.haskell.org/trac/ghc/wiki/SequentCore Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Luke | Maurer | Sent: 31 January 2017 23:48 | To: ghc-devs | Subject: Join points revised | | Revised version of the join points patch is up: | | https://phabricator.haskell.org/D2853 | | Hoping to commit ASAP. Thanks all! | | - Luke Maurer | University of Oregon | maurerl at cs.uoregon.edu | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell | .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C7917aef78e504851e95808d44a33f5 | e7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636215034407397385&sdata=3sy | y8B9rlJ0WDAuQXnzy83mBRRU%2BdmpczYezCmNrO%2B8%3D&reserved=0 From simonpj at microsoft.com Wed Feb 1 08:34:48 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 1 Feb 2017 08:34:48 +0000 Subject: D2038: [WIP] TysPrim: Generalize kind of (->) In-Reply-To: <9CF741E7-5985-4267-8ECA-5E5E7E870F57@cs.brynmawr.edu> References: <20170131125046.126142.13535.3FCE5C50@phabricator.haskell.org> <50EB9209-1A0F-4DA8-BA06-586DFD3C68DE@cs.brynmawr.edu> <9CF741E7-5985-4267-8ECA-5E5E7E870F57@cs.brynmawr.edu> Message-ID: 1. Hold off on Constraint v Type until after the branch is cut. Good idea. I think that’d be OK. It’s no worse than the status quo. I’m MUCH more keen to get the TypeRep stuff in, because it has been in the works for nearly two years!! So let’s do 1-3 pronto. Who is acting there. Just Ben? Or are there bits Richard needs to help with? As to 4 onwards I still want to talk to you about roles. Simon From: Richard Eisenberg [mailto:rae at cs.brynmawr.edu] Sent: 01 February 2017 01:19 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: D2038: [WIP] TysPrim: Generalize kind of (->) I had another thought on my drive home: why do we need to sort out Constraint v Type for 8.2? I have the patch, and it's essentially all set. But it weakens equality in a way that's troublesome for D2038 and introduces heterogeneous axioms, which are strange, ill-understood beasts. And I don't think we need it. On the other hand, D2038 is essential for the new Typeable, because it's the only way we can give (->) a proper kind. So, I propose: 1. Hold off on Constraint v Type until after the branch is cut. 2. Do what we can to mitigate Constraint v Type confusion vis-a-vis Typeable. (For example, make sure that there aren't Typeable instances for both, and have TcTypeable provide the Type instance whenever the Constraint instance is requested.) 3. Advertise that GHC will be a little confused on this point, and that, as far as Typeable is concerned, Constraint and Type are synonymous. 4. On the Constraint v Type patch, restore the full power of KindCo. This makes the type system broken, but I don't think the sky will come crashing down. 5. Merge Constraint v Type after the branch is cut. This will make GHC HEAD unsound in a new way, but no one will notice unless they try. 6. File a priority-highest bug to eliminate newtype-classes (which beget heterogeneous axioms in the Constraint/=Type world). 7. Finish the first-class reification design and implement before 8.4. 8. Remove newtype-classes, thus eliminating heterogeneous axioms and the unsoundness mentioned in (5). This route seems, to me, far preferable to monkeying around with roles and such in ways that we have no assurances are sound. (Remember, roles are there to keep the type system safe and sound. They were not added simply to annoy everyone, though they accomplish that goal quite nicely.) What do we think? It's not ideal, but I think it's the best of suboptimal alternatives. And it's no worse than 8.0 w.r.t. Constraint v Type. Richard On Jan 31, 2017, at 5:56 PM, Richard Eisenberg > wrote: On Jan 31, 2017, at 5:41 PM, Simon Peyton Jones > wrote: But that can only happen if `(->)` has suitable roles. What if it doesn’t? The “correct” roles for (->) of the kind you gave is `nominal nominal nominal nominal representational representational`. That is, the dependent arguments are nominal, and the others are representational. This is because all kind-level coercions are nominal. You seem to be suggesting giving (->) different roles. I honestly don’t know what that would mean -- normally, GHC prevents you from specifying a weaker role than it would infer. It smells pretty foul to me, but I can’t quite put my finger on what would go wrong at the moment. What if we just had an axiom axArrow v :: (->) Vanilla v ~R (->) Constraint v I think we’d also need one for results... but maybe not. or something like that. Then we get [W] g : (->) Vanilla Vanilla Ptr Ptr (C a) Int ~R (->) Constraint Vanilla Ptr Ptr a Int We decompose partly and solve thus g = (axArrow Vanilla) axC And this works only if we weaken (->)’s roles. This whole road just feels like the wrong way, as soon as we started contemplating a heterogeneous axiom, which are ruled out in the literature, even when we have kind equalities. I think the Right Answer is to get rid of newtype-classes & fix reify, and I’m worried that anything short of that will fail catastrophically at some point. Otherwise, it’s patches on top of patches. I don’t think there is disagreement here, but there is the question about what to do for 8.2.... and unless we’re ready to roll out the new reify, I think the best course of action is to delay the new Typeable and all this Constraint v Type stuff until 8.4. (The new levity polymorphism stuff already committed is hunky-dory.) Richard Simon From: noreply at phabricator.haskell.org [mailto:noreply at phabricator.haskell.org] Sent: 31 January 2017 12:51 To: Simon Peyton Jones > Subject: [Differential] [Commented On] D2038: [WIP] TysPrim: Generalize kind of (->) goldfire added a comment. View Revision In D2038#89360, @simonpj wrote: To avoid being able to extract ContraintRep ~R LiftedPtrRep we decided to weaken one of the coercion constructors, the one that gets a kind coercion from a type coercion. We don't need it, and it's awkward here. The problem is that we need it with this patch. I was able to weaken this coercion constructor (KindCo) in my patchD3023, but this patch uses it in a fundamental way that we can't get around. To wit: class C a where meth :: a axC :: (C a :: Constraint) ~R (a :: Type) Now, we wish to cast C a -> a to a -> a.. This cast will look like (->) ?? axC . What goes in the??? It's got to be something involving KindCo axC, which is disallowed as per our earlier decision. Therein lies the problem. As for reify: Yes, I'm agreed with that email. But is that implemented yet? Is a design settled on? I don't see a ghc-proposal. Are we wiling to take a dependency on that work in order to get this done? To be clear, my chief worry isn't that these problems cannot be solved by any means -- I'm just worried about the timing of this all and our desire to get 8.2 out the door. REPOSITORY rGHC Glasgow Haskell Compiler REVISION DETAIL https://phabricator.haskell.org/D2038 EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: bgamari, goldfire, austin Cc: simonpj, RyanGlScott, thomie _______________________________________________ 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 marlowsd at gmail.com Wed Feb 1 09:01:44 2017 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 1 Feb 2017 09:01:44 +0000 Subject: Lazy ST vs concurrency In-Reply-To: References: <1721492.EdgZeEtm4b@squirrel> Message-ID: On 31 January 2017 at 10:02, Simon Peyton Jones wrote: > Huh. You are right. That’s horrible. > Horrible indeed! > > > OK, here’s another idea. Provide, > > applyOnce# :: (a->b) -> a -> b > > > > which behaves like > > applyOnce f x = f x > > > > but guarantees that any thunk (applyOnce# f x) will be evaluated with > atomic eager black-holing. > > > > \(s :: State# s) -> > > let unsafePerformIO = \g -> g s > > thunk = applyOnce# unsafePerformIO (\s -> ... ) > > in > > ... > > But what if GHC decided to add another thunk, e.g. let thunk = let x = applyOnce# unsafePerformIO (\s -> ...) in x now we need atomicity on both thunks, but there's no way to tell. (of course GHC probably wouldn't do this particularly transformation, but there are a whole range of other things that it might correctly do that would subvert the programmer's intention to make a single atomic thunk). noDuplicate# avoids this problem because it walks the whole stack, claiming the whole chain of thunks currently under evaluation. But this is a messy solution, I don't like it either. Cheers Simon > Of course this does not guarantee safety. But I think it’d give a > per-thunk way to specify it. > > > > Simon > > > > *From:* Simon Marlow [mailto:marlowsd at gmail.com] > *Sent:* 31 January 2017 09:25 > > *To:* Simon Peyton Jones > *Cc:* David Feuer ; ghc-devs at haskell.org > *Subject:* Re: Lazy ST vs concurrency > > > > On 31 January 2017 at 09:11, Simon Peyton Jones > wrote: > > If we could identify exactly the thunks we wanted to be atomic, then yes, > that would be better than a whole-module solution. However I'm not sure > how to do that - doing it on the basis of a free variable with State# type > doesn't work if the State# is buried in a data structure or a function > closure, for instance. > > > > I disagree. Having a free State# variable is precisely necessary and > sufficient, I claim. Can you provide a counter-example? > > > > Sure, what I had in mind is something like this, defining a local > unsafePerformIO: > > > > \(s :: State# s) -> > > let unsafePerformIO = \g -> g s > > thunk = unsafePerformIO (\s -> ... ) > > in > > ... > > > > and "thunk" doesn't have a free variable of type State#. > > > > Cheers > > Simon > > > > > > Informal proof: > > · The model is that a value of type (State# t) is a linear value > that we mutate in-place. We must not consume it twice. > > · Evaluating a thunk that has a free (State# t) variable is > precisely “consuming” it. So we should only do that once > > > > > > I think -fatomic-eager-blackholing might "fix" it with less overhead, > though > > > > But precisely where would you have to use that flag? Inlining could meant > that the code appears anywhere! Once we have the ability to > atomically-blackhole a thunk, we can just use my criterion above, I claim. > > > > Stopgap story for 8.2. I am far from convinced that putting > unsafePerformIO in the impl of (>>=) for the ST monad will be correct; but > if you tell me it is, and if it is surrounded with huge banners saying that > this is the wrong solution, and pointing to a new ticket to fix it, then OK. > > > > Arguably this isn't all that urgent, given that it's been broken for 8 > years or so. > > > > > > Simon > > > > *From:* Simon Marlow [mailto:marlowsd at gmail.com] > *Sent:* 31 January 2017 08:59 > *To:* Simon Peyton Jones > *Cc:* David Feuer ; ghc-devs at haskell.org > > > *Subject:* Re: Lazy ST vs concurrency > > > > On 30 January 2017 at 22:56, Simon Peyton Jones > wrote: > > We don’t want to do this on a per-module basis do we, as > -fatomic-eager-blackholing would suggest. Rather, on per-thunk basis, no? > Which thunks, precisely? I think perhaps *precisely thunks one of whose > free variables has type (Sttate# s) for some s.* These are thunks that > consume a state token, and must do so no more than once. > > > > If we could identify exactly the thunks we wanted to be atomic, then yes, > that would be better than a whole-module solution. However I'm not sure > how to do that - doing it on the basis of a free variable with State# type > doesn't work if the State# is buried in a data structure or a function > closure, for instance. > > > > If entering such thunks was atomic, could we kill off noDuplicate#? > > > > I still don’t understand exactly what noDuplicate# does, what problem it > solves, and how the problem it solves relates to this LazyST problem. > > > > Back in our "Haskell on a Shared Memory Multiprocessor" paper ( > http://simonmar.github.io/bib/papers/multiproc.pdf > ) > we described a scheme to try to avoid duplication of work when multiple > cores evaluate the same thunk. This is normally applied lazily, because it > involves walking the stack and atomically black-holing thunks pointed to by > update frames. The noDuplicate# primop just invokes the stack walk > immediately; the idea is to try to prevent multiple threads from evaluating > a thunk containing unsafePerformIO. > > > > It's expensive. It's also not foolproof, because if you already happened > to create two copies of the unsafePerformIO thunk then noDuplicate# can't > help. I've never really liked it for these reasons, but I don't know a > better way. We have unsafeDupablePerformIO that doesn't call noDuplicate#, > and the programmer can use when the unsafePerformIO can safely be executed > multiple times. > > > > > > We need some kind of fix for 8.2. Simon what do you suggest? > > > > David's current fix would be OK (along with a clear notice in the release > notes etc. to note that the implementation got slower). I think > -fatomic-eager-blackholing might "fix" it with less overhead, though. > > > > Ben's suggestion: > > > > > eagerlyBlackhole :: a -> a > > > > is likely to be unreliable I think. We lack the control in the source > language to tie it to a particular thunk. > > > > Cheers > > Simon > > > > > > Simon > > > > *From:* Simon Marlow [mailto:marlowsd at gmail.com] > *Sent:* 30 January 2017 21:51 > *To:* David Feuer > *Cc:* Simon Peyton Jones ; ghc-devs at haskell.org > *Subject:* Re: Lazy ST vs concurrency > > > > On 30 January 2017 at 16:18, David Feuer wrote: > > I forgot to CC ghc-devs the first time, so here's another copy. > > > I was working on #11760 this weekend, which has to do with concurrency > breaking lazy ST. I came up with what I thought was a pretty decent > solution ( > https://phabricator.haskell.org/D3038 ). Simon Peyton Jones, however, is > quite > unhappy about the idea of sticking this weird unsafePerformIO-like code > (noDup, which I originally implemented as (unsafePerformIO . evaluate), but > which he finds ugly regardless of the details) into fmap and (>>=). He's > also > concerned that the noDuplicate# applications will kill performance in the > multi-threaded case, and suggests he would rather leave lazy ST broken, or > even remove it altogether, than use a fix that will make it slow sometimes, > particularly since there haven't been a lot of reports of problems in the > wild. > > > > In a nutshell, I think we have to fix this despite the cost - the > implementation is incorrect and unsafe. > > > > Unfortunately the mechanisms we have right now to fix it aren't ideal - > noDuplicate# is a bigger hammer than we need. All we really need is some > way to make a thunk atomic, it would require some special entry code to the > thunk which did atomic eager-blackholing. Hmm, now that I think about it, > perhaps we could just have a flag, -fatomic-eager-blackholing. We already > do this for CAFs, incidentally. The idea is to compare-and-swap the > blackhole info pointer into the thunk, and if we didn't win the race, just > re-enter the thunk (which is now a blackhole). We already have the cmpxchg > MachOp, so It shouldn't be more than a few lines in the code generator to > implement it. It would be too expensive to do by default, but doing it > just for Control.Monad.ST.Lazy should be ok and would fix the unsafety. > > > > (I haven't really thought this through, just an idea off the top of my > head, so there could well be something I'm overlooking here...) > > > > Cheers > > Simon > > > > > > My view is that leaving it broken, even if it only causes trouble > occasionally, is simply not an option. If users can't rely on it to always > give correct answers, then it's effectively useless. And for the sake of > backwards compatibility, I think it's a lot better to keep it around, even > if > it runs slowly multithreaded, than to remove it altogether. > > Note to Simon PJ: Yes, it's ugly to stick that noDup in there. But lazy ST > has > always been a bit of deep magic. You can't *really* carry a moment of time > around in your pocket and make its history happen only if necessary. We can > make it work in GHC because its execution model is entirely based around > graph > reduction, so evaluation is capable of driving execution. Whereas lazy IO > is > extremely tricky because it causes effects observable in the real world, > lazy > ST is only *moderately* tricky, causing effects that we have to make sure > don't lead to weird interactions between threads. I don't think it's > terribly > surprising that it needs to do a few more weird things to work properly. > > David > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Feb 1 09:48:00 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 1 Feb 2017 09:48:00 +0000 Subject: Lazy ST vs concurrency In-Reply-To: References: <1721492.EdgZeEtm4b@squirrel>

Message-ID: But what if GHC decided to add another thunk, e.g. Ugh. That is even more horrible. Clearly I’m not very good at thinking about this stuff. It smells wrong; we should find a simple, composable primitive that does the right thing. I’d like to leave some breadcrumbs of this thread, at very least pointing to it so we don’t repeat the thinking later. Meanwhile, for the present, what are we do to about LazyST? Simon From: Simon Marlow [mailto:marlowsd at gmail.com] Sent: 01 February 2017 09:02 To: Simon Peyton Jones Cc: David Feuer ; ghc-devs at haskell.org Subject: Re: Lazy ST vs concurrency On 31 January 2017 at 10:02, Simon Peyton Jones > wrote: Huh. You are right. That’s horrible. Horrible indeed! OK, here’s another idea. Provide, applyOnce# :: (a->b) -> a -> b which behaves like applyOnce f x = f x but guarantees that any thunk (applyOnce# f x) will be evaluated with atomic eager black-holing. \(s :: State# s) -> let unsafePerformIO = \g -> g s thunk = applyOnce# unsafePerformIO (\s -> ... ) in ... But what if GHC decided to add another thunk, e.g. let thunk = let x = applyOnce# unsafePerformIO (\s -> ...) in x now we need atomicity on both thunks, but there's no way to tell. (of course GHC probably wouldn't do this particularly transformation, but there are a whole range of other things that it might correctly do that would subvert the programmer's intention to make a single atomic thunk). noDuplicate# avoids this problem because it walks the whole stack, claiming the whole chain of thunks currently under evaluation. But this is a messy solution, I don't like it either. Cheers Simon Of course this does not guarantee safety. But I think it’d give a per-thunk way to specify it. Simon From: Simon Marlow [mailto:marlowsd at gmail.com] Sent: 31 January 2017 09:25 To: Simon Peyton Jones > Cc: David Feuer >; ghc-devs at haskell.org Subject: Re: Lazy ST vs concurrency On 31 January 2017 at 09:11, Simon Peyton Jones > wrote: If we could identify exactly the thunks we wanted to be atomic, then yes, that would be better than a whole-module solution. However I'm not sure how to do that - doing it on the basis of a free variable with State# type doesn't work if the State# is buried in a data structure or a function closure, for instance. I disagree. Having a free State# variable is precisely necessary and sufficient, I claim. Can you provide a counter-example? Sure, what I had in mind is something like this, defining a local unsafePerformIO: \(s :: State# s) -> let unsafePerformIO = \g -> g s thunk = unsafePerformIO (\s -> ... ) in ... and "thunk" doesn't have a free variable of type State#. Cheers Simon Informal proof: • The model is that a value of type (State# t) is a linear value that we mutate in-place. We must not consume it twice. • Evaluating a thunk that has a free (State# t) variable is precisely “consuming” it. So we should only do that once I think -fatomic-eager-blackholing might "fix" it with less overhead, though But precisely where would you have to use that flag? Inlining could meant that the code appears anywhere! Once we have the ability to atomically-blackhole a thunk, we can just use my criterion above, I claim. Stopgap story for 8.2. I am far from convinced that putting unsafePerformIO in the impl of (>>=) for the ST monad will be correct; but if you tell me it is, and if it is surrounded with huge banners saying that this is the wrong solution, and pointing to a new ticket to fix it, then OK. Arguably this isn't all that urgent, given that it's been broken for 8 years or so. Simon From: Simon Marlow [mailto:marlowsd at gmail.com] Sent: 31 January 2017 08:59 To: Simon Peyton Jones > Cc: David Feuer >; ghc-devs at haskell.org Subject: Re: Lazy ST vs concurrency On 30 January 2017 at 22:56, Simon Peyton Jones > wrote: We don’t want to do this on a per-module basis do we, as -fatomic-eager-blackholing would suggest. Rather, on per-thunk basis, no? Which thunks, precisely? I think perhaps precisely thunks one of whose free variables has type (Sttate# s) for some s. These are thunks that consume a state token, and must do so no more than once. If we could identify exactly the thunks we wanted to be atomic, then yes, that would be better than a whole-module solution. However I'm not sure how to do that - doing it on the basis of a free variable with State# type doesn't work if the State# is buried in a data structure or a function closure, for instance. If entering such thunks was atomic, could we kill off noDuplicate#? I still don’t understand exactly what noDuplicate# does, what problem it solves, and how the problem it solves relates to this LazyST problem. Back in our "Haskell on a Shared Memory Multiprocessor" paper (http://simonmar.github.io/bib/papers/multiproc.pdf) we described a scheme to try to avoid duplication of work when multiple cores evaluate the same thunk. This is normally applied lazily, because it involves walking the stack and atomically black-holing thunks pointed to by update frames. The noDuplicate# primop just invokes the stack walk immediately; the idea is to try to prevent multiple threads from evaluating a thunk containing unsafePerformIO. It's expensive. It's also not foolproof, because if you already happened to create two copies of the unsafePerformIO thunk then noDuplicate# can't help. I've never really liked it for these reasons, but I don't know a better way. We have unsafeDupablePerformIO that doesn't call noDuplicate#, and the programmer can use when the unsafePerformIO can safely be executed multiple times. We need some kind of fix for 8.2. Simon what do you suggest? David's current fix would be OK (along with a clear notice in the release notes etc. to note that the implementation got slower). I think -fatomic-eager-blackholing might "fix" it with less overhead, though. Ben's suggestion: > eagerlyBlackhole :: a -> a is likely to be unreliable I think. We lack the control in the source language to tie it to a particular thunk. Cheers Simon Simon From: Simon Marlow [mailto:marlowsd at gmail.com] Sent: 30 January 2017 21:51 To: David Feuer > Cc: Simon Peyton Jones >; ghc-devs at haskell.org Subject: Re: Lazy ST vs concurrency On 30 January 2017 at 16:18, David Feuer > wrote: I forgot to CC ghc-devs the first time, so here's another copy. I was working on #11760 this weekend, which has to do with concurrency breaking lazy ST. I came up with what I thought was a pretty decent solution ( https://phabricator.haskell.org/D3038 ). Simon Peyton Jones, however, is quite unhappy about the idea of sticking this weird unsafePerformIO-like code (noDup, which I originally implemented as (unsafePerformIO . evaluate), but which he finds ugly regardless of the details) into fmap and (>>=). He's also concerned that the noDuplicate# applications will kill performance in the multi-threaded case, and suggests he would rather leave lazy ST broken, or even remove it altogether, than use a fix that will make it slow sometimes, particularly since there haven't been a lot of reports of problems in the wild. In a nutshell, I think we have to fix this despite the cost - the implementation is incorrect and unsafe. Unfortunately the mechanisms we have right now to fix it aren't ideal - noDuplicate# is a bigger hammer than we need. All we really need is some way to make a thunk atomic, it would require some special entry code to the thunk which did atomic eager-blackholing. Hmm, now that I think about it, perhaps we could just have a flag, -fatomic-eager-blackholing. We already do this for CAFs, incidentally. The idea is to compare-and-swap the blackhole info pointer into the thunk, and if we didn't win the race, just re-enter the thunk (which is now a blackhole). We already have the cmpxchg MachOp, so It shouldn't be more than a few lines in the code generator to implement it. It would be too expensive to do by default, but doing it just for Control.Monad.ST.Lazy should be ok and would fix the unsafety. (I haven't really thought this through, just an idea off the top of my head, so there could well be something I'm overlooking here...) Cheers Simon My view is that leaving it broken, even if it only causes trouble occasionally, is simply not an option. If users can't rely on it to always give correct answers, then it's effectively useless. And for the sake of backwards compatibility, I think it's a lot better to keep it around, even if it runs slowly multithreaded, than to remove it altogether. Note to Simon PJ: Yes, it's ugly to stick that noDup in there. But lazy ST has always been a bit of deep magic. You can't *really* carry a moment of time around in your pocket and make its history happen only if necessary. We can make it work in GHC because its execution model is entirely based around graph reduction, so evaluation is capable of driving execution. Whereas lazy IO is extremely tricky because it causes effects observable in the real world, lazy ST is only *moderately* tricky, causing effects that we have to make sure don't lead to weird interactions between threads. I don't think it's terribly surprising that it needs to do a few more weird things to work properly. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Wed Feb 1 13:53:53 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 1 Feb 2017 08:53:53 -0500 Subject: D2038: [WIP] TysPrim: Generalize kind of (->) In-Reply-To: References: <20170131125046.126142.13535.3FCE5C50@phabricator.haskell.org> <50EB9209-1A0F-4DA8-BA06-586DFD3C68DE@cs.brynmawr.edu> <9CF741E7-5985-4267-8ECA-5E5E7E870F57@cs.brynmawr.edu> Message-ID: <8DD87CB3-926F-48CF-B71C-E71069E997A9@cs.brynmawr.edu> > On Feb 1, 2017, at 3:34 AM, Simon Peyton Jones wrote: > > Who is acting there. Just Ben? Or are there bits Richard needs to help with? Ben has done the real heavy lifting, with me opining on this bit or that. From what Ben says, it's very close. There is a small bit of new work to be done to prefer Type over Constraint when solving for Typeable (my step 2), but that can't be hard. If I'm released (for now) from #11715, what's the next priority for me? Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwbarton at gmail.com Wed Feb 1 18:26:10 2017 From: rwbarton at gmail.com (Reid Barton) Date: Wed, 1 Feb 2017 13:26:10 -0500 Subject: More history in perf.haskell.org graphs Message-ID: Hi Joachim, The graphs like https://perf.haskell.org/ghc/#graph/buildtime/make are very helpful, but I haven't found a way to adjust the range of commits shown from the default of the last 50 commits. For example, suppose I wanted to see the history of build time over the past 12 months and then narrow in on commits that caused regressions. Is there a way to do that using the https://perf.haskell.org/ghc/ website? Failing that, is the data that goes into these graphs available for download in some form? Regards, Reid Barton From ben at smart-cactus.org Wed Feb 1 18:42:23 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 01 Feb 2017 13:42:23 -0500 Subject: More history in perf.haskell.org graphs In-Reply-To: References: Message-ID: <87fujxkb1s.fsf@ben-laptop.smart-cactus.org> Reid Barton writes: > Hi Joachim, > > The graphs like https://perf.haskell.org/ghc/#graph/buildtime/make are > very helpful, but I haven't found a way to adjust the range of commits > shown from the default of the last 50 commits. For example, suppose I > wanted to see the history of build time over the past 12 months and > then narrow in on commits that caused regressions. Is there a way to > do that using the https://perf.haskell.org/ghc/ website? > This is precisely the goal of my own ghc-perf tool [1], although it has sadly languished in the recent months. I really need to work out some Postgrest performance issues and find a more reliable hosting situation for it. > Failing that, is the data that goes into these graphs available for > download in some form? > Joachim can likely provide a more helpful answer, but at very least the logs are available here [2]. I use a set of scripts [3] to extract performance numbers from these logs into PostgreSQL. Cheers, - Ben [1] http://home.smart-cactus.org/~ben/ghc-perf/ [2] https://github.com/nomeata/ghc-speed-logs [3] https://github.com/bgamari/ghc-perf-import/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mail at joachim-breitner.de Wed Feb 1 19:07:21 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 01 Feb 2017 14:07:21 -0500 Subject: More history in perf.haskell.org graphs In-Reply-To: References: Message-ID: <1485976041.14724.10.camel@joachim-breitner.de> Hi, Am Mittwoch, den 01.02.2017, 13:26 -0500 schrieb Reid Barton: > The graphs like https://perf.haskell.org/ghc/#graph/buildtime/make > are very helpful, but I haven't found a way to adjust the range of commits > shown from the default of the last 50 commits. For example, suppose I > wanted to see the history of build time over the past 12 months and > then narrow in on commits that caused regressions. Is there a way to > do that using the https://perf.haskell.org/ghc/ website? > this is simply a missing feature. When building gipeda I ran out of steam before implementing that. Patches welcome ;-) Or use Ben’s work, which is pretty rad. Greetings, Joachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Wed Feb 1 22:55:25 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 1 Feb 2017 22:55:25 +0000 Subject: D2038: [WIP] TysPrim: Generalize kind of (->) In-Reply-To: <8DD87CB3-926F-48CF-B71C-E71069E997A9@cs.brynmawr.edu> References: <20170131125046.126142.13535.3FCE5C50@phabricator.haskell.org> <50EB9209-1A0F-4DA8-BA06-586DFD3C68DE@cs.brynmawr.edu> <9CF741E7-5985-4267-8ECA-5E5E7E870F57@cs.brynmawr.edu> <8DD87CB3-926F-48CF-B71C-E71069E997A9@cs.brynmawr.edu> Message-ID: Check out https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.2.1 There are several tickets you own in highest or high prio. Notably #12919 (an outright bug). And #12670, #13160, #13202 BEN: yell for whatever help you need with (->) and Typable Simon From: Richard Eisenberg [mailto:rae at cs.brynmawr.edu] Sent: 01 February 2017 13:54 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: D2038: [WIP] TysPrim: Generalize kind of (->) On Feb 1, 2017, at 3:34 AM, Simon Peyton Jones > wrote: Who is acting there. Just Ben? Or are there bits Richard needs to help with? Ben has done the real heavy lifting, with me opining on this bit or that. From what Ben says, it's very close. There is a small bit of new work to be done to prefer Type over Constraint when solving for Typeable (my step 2), but that can't be hard. If I'm released (for now) from #11715, what's the next priority for me? Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Wed Feb 1 23:36:56 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 01 Feb 2017 18:36:56 -0500 Subject: D2038: [WIP] TysPrim: Generalize kind of (->) In-Reply-To: References: <20170131125046.126142.13535.3FCE5C50@phabricator.haskell.org> <50EB9209-1A0F-4DA8-BA06-586DFD3C68DE@cs.brynmawr.edu> <9CF741E7-5985-4267-8ECA-5E5E7E870F57@cs.brynmawr.edu> <8DD87CB3-926F-48CF-B71C-E71069E997A9@cs.brynmawr.edu> Message-ID: <87inotiiuf.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Check out > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.2.1 > > There are several tickets you own in highest or high prio. Notably #12919 (an outright bug). And #12670, #13160, #13202 > > BEN: yell for whatever help you need with (->) and Typable > Thanks Simon! I think I probably have it from here. Cheers, - Ben Richard says, > > If I'm released (for now) from #11715, what's the next priority for me? > I would say #12919 is the most important. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Thu Feb 2 12:36:33 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 2 Feb 2017 12:36:33 +0000 Subject: Master broken? Message-ID: My clean build of origin/master, on 64-bit Linux is showing these failures Unexpected failures: /tmp/ghctest-5_qx1p/test spaces/./pmcheck/should_compile/T11195.run T11195 [exit code non-0] (normal) Unexpected stat failures: /tmp/ghctest-5_qx1p/test spaces/./perf/compiler/T5837.run T5837 [stat too good] (normal) /tmp/ghctest-5_qx1p/test spaces/./perf/compiler/T12234.run T12234 [stat too good] (optasm) (I do wish the summary omitted those long paths; makes it hard to read.) I'm happy about the perf improvements, but why don't they happen for other people? T11195 is a very long-running pattern-match perf test that regularly fails on a heavily loaded machine, with a timeout. It's very tiresome, but I don't think it's a regression. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Thu Feb 2 16:44:36 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 02 Feb 2017 11:44:36 -0500 Subject: Master broken? In-Reply-To: References: Message-ID: <87a8a4ilu3.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > My clean build of origin/master, on 64-bit Linux is showing these failures > > Unexpected failures: > > /tmp/ghctest-5_qx1p/test spaces/./pmcheck/should_compile/T11195.run T11195 [exit code non-0] (normal) > > > > Unexpected stat failures: > > /tmp/ghctest-5_qx1p/test spaces/./perf/compiler/T5837.run T5837 [stat too good] (normal) > > /tmp/ghctest-5_qx1p/test spaces/./perf/compiler/T12234.run T12234 [stat too good] (optasm) > > (I do wish the summary omitted those long paths; makes it hard to read.) > I'm happy about the perf improvements, but why don't they happen for other people? I bumped the allocation numbers for T12234 yesterday as it was failing on Darwin. It currently passes for my on x86_64/Linux. I'm not sure what to make of this. It quite frustrating how much environmental sensitivity these tests have. I personally this this is good motivation to follow through on #12758. > T11195 is a very long-running pattern-match perf test that regularly > fails on a heavily loaded machine, with a timeout. It's very tiresome, > but I don't think it's a regression. Yes, I have seen this on a few occassions, but not recently. I'm not sure what we can do other than bumping the timeout a bit. 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 Thu Feb 2 21:16:58 2017 From: david.feuer at gmail.com (David Feuer) Date: Thu, 2 Feb 2017 16:16:58 -0500 Subject: eagerlyBlackhole# efficiency thought In-Reply-To: References:

Message-ID: We discussed trying to come up with a primitive eagerlyBlackhole# :: a -> a -- meaning eagerlyBlackhole a = runRW# $ \s -> case noDuplicate# s of _ -> a that would guarantee that the thunk is entered by only one thread. There are important situations where that check is redundant. Consider this code: (m >>= \a -> strictToLazyST (f a)) >>= o The implementation of >>= needs to wrap up the execution of its first argument in eagerlyBlackhole#. In this case, however, there is no risk that two threads will execute m, because it's forced within the same outer eagerlyBlackhole in which it was created. Is there a cheap way to detect this situation at run-time, when executing m, to avoid the synchronization delay? This probably doesn't arise too much for unsafePerformIO, but in lazy ST there may be a lot of nested no-duplicate thunks. I looked into trying to fix things up with RULES for *> and such, but I ran into trouble with eta expansion and in any case there are limits to what they can do to help >>=, and the whole thing is rather complicated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Feb 2 21:36:23 2017 From: ben at well-typed.com (Ben Gamari) Date: Thu, 02 Feb 2017 16:36:23 -0500 Subject: Talkative Join points warning Message-ID: <87y3xogtrc.fsf@ben-laptop.smart-cactus.org> Hi Luke, I've noticed that a new WARN in OccurAnal seems to be quite loud. Validations now produce thousands of lines of the form, WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$j_shTG] WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$w$j_sl22] WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$w$j_sl1W] WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$w$j_sl1Q] Do you think we could either quiet the warning down a bit or perhaps disable it by default? It makes it rather difficult to see through the noise. This is actually perhaps another case where Simon Marlow suggestion of introducing a family of -v* flags (e.g. -fvanishing-join-points) might be helpful. 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 matthewtpickering at gmail.com Thu Feb 2 23:29:08 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 2 Feb 2017 23:29:08 +0000 Subject: Talkative Join points warning In-Reply-To: <87y3xogtrc.fsf@ben-laptop.smart-cactus.org> References: <87y3xogtrc.fsf@ben-laptop.smart-cactus.org> Message-ID: #13221 is related On Thu, Feb 2, 2017 at 9:36 PM, Ben Gamari wrote: > > Hi Luke, > > I've noticed that a new WARN in OccurAnal seems to be quite loud. > Validations now produce thousands of lines of the form, > > WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 > OccurAnal failed to rediscover join point(s): [$j_shTG] > WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 > OccurAnal failed to rediscover join point(s): [$w$j_sl22] > WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 > OccurAnal failed to rediscover join point(s): [$w$j_sl1W] > WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 > OccurAnal failed to rediscover join point(s): [$w$j_sl1Q] > > Do you think we could either quiet the warning down a bit or perhaps > disable it by default? It makes it rather difficult to see through the > noise. > > This is actually perhaps another case where Simon Marlow suggestion of > introducing a family of -v* flags (e.g. -fvanishing-join-points) might > be helpful. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Thu Feb 2 23:37:55 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 2 Feb 2017 23:37:55 +0000 Subject: Talkative Join points warning In-Reply-To: <87y3xogtrc.fsf@ben-laptop.smart-cactus.org> References: <87y3xogtrc.fsf@ben-laptop.smart-cactus.org> Message-ID: Better still, figure out why it's happening and stop it happening. It shouldn't! S | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ben | Gamari | Sent: 02 February 2017 21:36 | To: Luke Maurer | Cc: ghc-devs at haskell.org | Subject: Talkative Join points warning | | | Hi Luke, | | I've noticed that a new WARN in OccurAnal seems to be quite loud. | Validations now produce thousands of lines of the form, | | WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 | OccurAnal failed to rediscover join point(s): [$j_shTG] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 | OccurAnal failed to rediscover join point(s): [$w$j_sl22] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 | OccurAnal failed to rediscover join point(s): [$w$j_sl1W] | WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 | OccurAnal failed to rediscover join point(s): [$w$j_sl1Q] | | Do you think we could either quiet the warning down a bit or perhaps | disable it by default? It makes it rather difficult to see through the | noise. | | This is actually perhaps another case where Simon Marlow suggestion of | introducing a family of -v* flags (e.g. -fvanishing-join-points) might be | helpful. | | Cheers, | | - Ben From maurerl at cs.uoregon.edu Fri Feb 3 00:51:44 2017 From: maurerl at cs.uoregon.edu (Luke Maurer) Date: Thu, 2 Feb 2017 16:51:44 -0800 Subject: Talkative Join points warning In-Reply-To: References: <87y3xogtrc.fsf@ben-laptop.smart-cactus.org> Message-ID: Agreed! Filed this one as bug #13221 yesterday: https://ghc.haskell.org/trac/ghc/ticket/13221 I'll have a look right now, in case it's an easy fix. - Luke On 02/02/2017 03:37 PM, Simon Peyton Jones wrote: > Better still, figure out why it's happening and stop it happening. It shouldn't! > > S > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ben > | Gamari > | Sent: 02 February 2017 21:36 > | To: Luke Maurer > | Cc: ghc-devs at haskell.org > | Subject: Talkative Join points warning > | > | > | Hi Luke, > | > | I've noticed that a new WARN in OccurAnal seems to be quite loud. > | Validations now produce thousands of lines of the form, > | > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 > | OccurAnal failed to rediscover join point(s): [$j_shTG] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 > | OccurAnal failed to rediscover join point(s): [$w$j_sl22] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 > | OccurAnal failed to rediscover join point(s): [$w$j_sl1W] > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 > | OccurAnal failed to rediscover join point(s): [$w$j_sl1Q] > | > | Do you think we could either quiet the warning down a bit or perhaps > | disable it by default? It makes it rather difficult to see through the > | noise. > | > | This is actually perhaps another case where Simon Marlow suggestion of > | introducing a family of -v* flags (e.g. -fvanishing-join-points) might be > | helpful. > | > | Cheers, > | > | - Ben > From chrisdone at gmail.com Fri Feb 3 12:21:38 2017 From: chrisdone at gmail.com (Christopher Done) Date: Fri, 3 Feb 2017 12:21:38 +0000 Subject: Disable messages with GHC API Message-ID: In Intero, after loading modules, for each one I run the following function: https://github.com/commercialhaskell/intero/blob/300ac5a/src/GhciInfo.hs#L75..L85 If there are warnings or any output, they get outputted. As they are already outputted by regular :load, I don’t need the same output twice. How do I disable non-severe output for any GhcMonad m => m a? I’m using GHC 8.0.1 presently. I tried the following before calling getModInfo, expecting there to be no output anymore: + GHC.setSessionDynFlags + df {log_action = \ref dflags severity srcSpan style msg -> return ()} And this had no effect. I tried some other things but ran out of patience to keep a record of them all. Ciao! From matthewtpickering at gmail.com Fri Feb 3 12:50:54 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 3 Feb 2017 12:50:54 +0000 Subject: Disable messages with GHC API In-Reply-To: References: Message-ID: The errors are eventually caught and printed by "handleSourceError" which is used a few times in your code. You could either modify one of these to not print out any errors or try something more intelligent like is in `parUpsweep_one` which does use the `log_action` in order to print the errors out. On Fri, Feb 3, 2017 at 12:21 PM, Christopher Done wrote: > In Intero, after loading modules, for each one I run the following > function: https://github.com/commercialhaskell/intero/blob/300ac5a/src/GhciInfo.hs#L75..L85 > > If there are warnings or any output, they get outputted. As they are > already outputted by regular :load, I don’t need the same output > twice. > > How do I disable non-severe output for any GhcMonad m => m a? I’m > using GHC 8.0.1 presently. > > I tried the following before calling getModInfo, expecting there to be > no output anymore: > > + GHC.setSessionDynFlags > + df {log_action = \ref dflags severity srcSpan style msg -> return ()} > > And this had no effect. I tried some other things but ran out of > patience to keep a record of them all. > > Ciao! > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at smart-cactus.org Fri Feb 3 15:23:57 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 03 Feb 2017 10:23:57 -0500 Subject: Panic from rewritableTyVarsOfType In-Reply-To: References: <87vassgpkf.fsf@ben-laptop.smart-cactus.org> Message-ID: <87r33fguwi.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones writes: > Ben, Richard > > rewritableTyVarsOfType is used when deciding whether to split a [WD] > constraint into [W] and [D]. For example, if we are adding > [WD] C a > and there is an inert > [WD] a ~ Int > then we want to split the [WD] into > [W] C a > [D] C a > so that the [D] one can be rewritten and perhaps yield improvement etc. > > There is no point in rewriting coercions or cases in t, because they > won't help (C t) to reduce. That's why rewriteableTyVarsOfType differs > from tyVarsOfType. And indeed the arg of a class C should be a > monotype. > Ahh, I see. > So rewriteableTyVarsOfType doesn't expect foralls, hence the panic. > But it's seeing a forall in an /equality/ constraint. > > FIRST ISSUE: I'm a bit surprised about that (smacks of impredicative > polymorphism) so the first thing to check is that this is really > supposed to happen in this program. Richard should be able to help. > Indeed this test is meant to fail, just not with a panic. I suspect this means that my solver logic isn't catching requests for polytypes as early as it needs to. > SECOND ISSUE: But regardless, I now realise that shouldSplitWD only > needs to split a [WD] equality if the LHS matches. If we have > [WD] a ~ ty -- work item > [D] a ~ ty2 -- inert > then we want to split the [WD] so we can get [D] ty ~ ty2. But > otherwise there is no point. > > Richard do you agree? > > I'll try that out. > > Meanwhile to get you rolling, you can replace rewritableTyVars with > tyCoVarsOfType and it'll all work, just a bit less efficiently. > Thanks Simon! Indeed that allows things to proceed and in the process, confirms that there is a bug in my solver logic. 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 chrisdone at gmail.com Fri Feb 3 15:30:21 2017 From: chrisdone at gmail.com (Christopher Done) Date: Fri, 3 Feb 2017 15:30:21 +0000 Subject: Disable messages with GHC API In-Reply-To: References: Message-ID: Adding `handleSourceError` around it makes no difference. Which makes sense, as I don't think warnings count as exceptions, otherwise my code would never have completed in the first place. On 3 February 2017 at 12:50, Matthew Pickering wrote: > The errors are eventually caught and printed by "handleSourceError" > which is used a few times in your code. You could either modify one of > these to not print out any errors or try something more intelligent > like is in `parUpsweep_one` which does use the `log_action` in order > to print the errors out. > > On Fri, Feb 3, 2017 at 12:21 PM, Christopher Done wrote: >> In Intero, after loading modules, for each one I run the following >> function: https://github.com/commercialhaskell/intero/blob/300ac5a/src/GhciInfo.hs#L75..L85 >> >> If there are warnings or any output, they get outputted. As they are >> already outputted by regular :load, I don’t need the same output >> twice. >> >> How do I disable non-severe output for any GhcMonad m => m a? I’m >> using GHC 8.0.1 presently. >> >> I tried the following before calling getModInfo, expecting there to be >> no output anymore: >> >> + GHC.setSessionDynFlags >> + df {log_action = \ref dflags severity srcSpan style msg -> return ()} >> >> And this had no effect. I tried some other things but ran out of >> patience to keep a record of them all. >> >> Ciao! >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From dxld at darkboxed.org Fri Feb 3 15:57:07 2017 From: dxld at darkboxed.org (Daniel =?iso-8859-1?Q?Gr=F6ber?=) Date: Fri, 3 Feb 2017 16:57:07 +0100 Subject: Disable messages with GHC API In-Reply-To: References: Message-ID: <20170203155707.iglqzfpkuxa76pjk@Eli.lan> On Fri, Feb 03, 2017 at 12:21:38PM +0000, Christopher Done wrote: > I tried the following before calling getModInfo, expecting there to be > no output anymore: > > + GHC.setSessionDynFlags > + df {log_action = \ref dflags severity srcSpan style msg -> return ()} That is pretty much exactly what I do in ghc-mod to suppress all output (other than the SourceError exceptions) so it's strange that wouldn't work. Have you tried making a small self contained test case for your problem, maybe it's something intero specific? How far has it diverged from it's GHCi roots these days anyways? Here's[1] a small testcase I usually modify to test various GHC oddities when I'm not sure if my ghc-mod monad magic is doing something werid or not, might be helpful: [1]: https://github.com/DanielG/ghc-mod/blob/master/test/manual/not-interpreted-error/GhcTestcase.hs --Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From matthewtpickering at gmail.com Fri Feb 3 15:59:09 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 3 Feb 2017 15:59:09 +0000 Subject: Disable messages with GHC API In-Reply-To: References:

Message-ID: You are right. I looked more closely now and it looks like "parseModule" and so on overwrite the DynFlags with a cached version before running the relevant piece of the pipeline. 857 hsc_env <- getSession 858 let hsc_env_tmp = hsc_env { hsc_dflags = ms_hspp_opts ms } 859 hpm <- liftIO $ hscParse hsc_env_tmp ms I think this is symptom of the fact that DynFlags is not very well structured and a lot of different compiler options are lumped together. It makes sense that we need to use the right DynFlags to run the module but this shouldn't overwrite things which are irrelevant like log_action. Matt On Fri, Feb 3, 2017 at 3:30 PM, Christopher Done wrote: > Adding `handleSourceError` around it makes no difference. > > Which makes sense, as I don't think warnings count as exceptions, > otherwise my code would never have completed in the first place. > > On 3 February 2017 at 12:50, Matthew Pickering > wrote: >> The errors are eventually caught and printed by "handleSourceError" >> which is used a few times in your code. You could either modify one of >> these to not print out any errors or try something more intelligent >> like is in `parUpsweep_one` which does use the `log_action` in order >> to print the errors out. >> >> On Fri, Feb 3, 2017 at 12:21 PM, Christopher Done wrote: >>> In Intero, after loading modules, for each one I run the following >>> function: https://github.com/commercialhaskell/intero/blob/300ac5a/src/GhciInfo.hs#L75..L85 >>> >>> If there are warnings or any output, they get outputted. As they are >>> already outputted by regular :load, I don’t need the same output >>> twice. >>> >>> How do I disable non-severe output for any GhcMonad m => m a? I’m >>> using GHC 8.0.1 presently. >>> >>> I tried the following before calling getModInfo, expecting there to be >>> no output anymore: >>> >>> + GHC.setSessionDynFlags >>> + df {log_action = \ref dflags severity srcSpan style msg -> return ()} >>> >>> And this had no effect. I tried some other things but ran out of >>> patience to keep a record of them all. >>> >>> Ciao! >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at smart-cactus.org Fri Feb 3 16:01:09 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 03 Feb 2017 11:01:09 -0500 Subject: Panic from rewritableTyVarsOfType In-Reply-To: <87r33fguwi.fsf@ben-laptop.smart-cactus.org> References: <87vassgpkf.fsf@ben-laptop.smart-cactus.org> <87r33fguwi.fsf@ben-laptop.smart-cactus.org> Message-ID: <87o9yjgt6i.fsf@ben-laptop.smart-cactus.org> Ben Gamari writes: > Simon Peyton Jones writes: > >> Meanwhile to get you rolling, you can replace rewritableTyVars with >> tyCoVarsOfType and it'll all work, just a bit less efficiently. >> > Thanks Simon! Indeed that allows things to proceed and in the process, > confirms that there is a bug in my solver logic. > I should clarify: the bug is in fact not in the Typeable solver. The problem is that we have a type with some kind polymorphism. For instance, data Proxy (a :: k) = Proxy Note that in order to be `Typeable` Proxy needs to have its `k` kind argument instantiated. Consequently this program is perfectly fine, ty :: TypeRep (Proxy Int) ty = typeRep We can even decompose this into a type application, case ty of TRApp a b -> ... where `a :: TypeRep Proxy` (with `k ~ Type`) and `b :: TypeRep Int`. However, if we attempt to decompose `a` again (which is what the Typeable1 testcase described in this thread tests), we run into trouble, case a of TRApp x y -> ... After changing rewritableTyVars with tyCoVarsOfType, the testcase Typeable1 fails with the following correct, albeit not terribly readable, error message, Typeable1.hs:22:5: error: • Couldn't match kind ‘* -> (* -> *) -> (* -> *) -> * -> *’ with ‘forall k. (* -> *) -> (k -> *) -> k -> *’ Inaccessible code in a pattern with pattern synonym: TRApp :: forall k2 (t :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). t ~ a b => TypeRep (k1 -> k2) a -> TypeRep k1 b -> TypeRep k2 t, in a pattern binding in 'do' block • In the pattern: TRApp x y In a stmt of a 'do' block: TRApp x y <- pure x In the expression: do let x :: ComposeK Maybe Maybe Int x = undefined TRApp x y <- pure $ typeOf x print (x, y) TRApp x y <- pure x .... • Relevant bindings include y :: TypeRep k3 b2 (bound at Typeable1.hs:19:13) x :: TypeRep (k3 -> k2 -> k1 -> *) a2 (bound at Typeable1.hs:19:11) This might be a place where GHC could hold the user's hand a bit more gently. Anyways, hopefully this will be resolved with the fix to Simon's second issue. Otherwise I just need to look at two performance regressions and I think I'm done. 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 alan.zimm at gmail.com Fri Feb 3 16:20:44 2017 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 3 Feb 2017 18:20:44 +0200 Subject: Disable messages with GHC API In-Reply-To: References:

Message-ID: <1486573465.19338.2.camel@joachim-breitner.de> Hi, Am Mittwoch, den 08.02.2017, 12:47 +0000 schrieb Andrey Mokhov: > Does Hadrian speed up a build from scratch? > > Hadrian can build GHC on Windows (AppVeyor) and Linux (Travis) CI > instances in about 40 mins using the 'quickest' build flavour (no > optimisation/docs). > > https://ci.appveyor.com/project/snowleopard/hadrian > https://travis-ci.org/snowleopard/hadrian > > On Travis OSX we recently started to time out (jobs are terminated at > 48 mins), even though I'm using another trick to save build time on > OSX: building with the --integer-simple flag, which skips building > the GMP library. does the testsuite (excluding perf tests, I guess) work with the quickest flavor? Greetings, Joachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at well-typed.com Wed Feb 8 17:16:11 2017 From: ben at well-typed.com (Ben Gamari) Date: Wed, 08 Feb 2017 12:16:11 -0500 Subject: Build time over travis time limit again In-Reply-To: <1486573465.19338.2.camel@joachim-breitner.de> References:

<1486573465.19338.2.camel@joachim-breitner.de> Message-ID: <874m04eh7o.fsf@ben-laptop.smart-cactus.org> Joachim Breitner writes: > Hi, > > Am Mittwoch, den 08.02.2017, 12:47 +0000 schrieb Andrey Mokhov: >> Does Hadrian speed up a build from scratch? >> >> Hadrian can build GHC on Windows (AppVeyor) and Linux (Travis) CI >> instances in about 40 mins using the 'quickest' build flavour (no >> optimisation/docs). >> >> https://ci.appveyor.com/project/snowleopard/hadrian >> https://travis-ci.org/snowleopard/hadrian >> >> On Travis OSX we recently started to time out (jobs are terminated at >> 48 mins), even though I'm using another trick to save build time on >> OSX: building with the --integer-simple flag, which skips building >> the GMP library. > > does the testsuite (excluding perf tests, I guess) work with the > quickest flavor? > Some ways won't work I would imagine, but I don't see why not. 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 ryan.gl.scott at gmail.com Thu Feb 9 16:20:22 2017 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 9 Feb 2017 11:20:22 -0500 Subject: 8.2.1 Status Message-ID: Hi Ben, Sorry for not asking this sooner, but I'd like to merge some form of https://phabricator.haskell.org/D2961 in time for 8.2 if possible. Sadly, doing it "the right way" (according to Simon) is proving to be extremely challenging. A previous iteration of D2961 does work (albeit the code is not as pretty as it ought to be). Are you still planning to cut the 8.2 release tomorrow? If so, I think I'll revert back to the working version of D2961 and merge that, and leave doing it the right way as future work. Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.mokhov at newcastle.ac.uk Thu Feb 9 17:32:23 2017 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Thu, 9 Feb 2017 17:32:23 +0000 Subject: Build time over travis time limit again References: Message-ID: Joachim, Ben, I gave it a try on my machine. First of all, we currently need "--flavour=quick" instead of "quickest" because the latter builds only vanilla RTS. If I do: ./build.bat -j --flavour=quick ./build.bat -j --flavour=quick validate Then the testsuite completes, but I get a lot of errors, particularly in "ghci/", "perf/" and "th/". Most of them can probably be fixed relatively easily in Hadrian, but this requires a good understanding of which GHC features these tests actually depend on. I'll create an issue in the Hadrian repo to track down these testsuite failures and will CC you. Cheers, Andrey From mail at joachim-breitner.de Thu Feb 9 18:13:10 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 09 Feb 2017 13:13:10 -0500 Subject: Build time over travis time limit again In-Reply-To: <1486508954.28707.1.camel@joachim-breitner.de> References: <1486508954.28707.1.camel@joachim-breitner.de> Message-ID: <1486663990.13286.2.camel@joachim-breitner.de> Hi, Am Dienstag, den 07.02.2017, 18:09 -0500 schrieb Joachim Breitner: > I will ask for more time from them. But if you know a way to keep > build times down, that’d be great. we got 90 minutes now… Due to the broken window effect, we now have two failures: TH_addCStub1(normal) 4122 of 5714 [0, 0, 0]--- /tmp/ghctest-u7xmp5/test spaces/./th/TH_addCStub2.run/TH_addCStub2.stderr.normalised 2017-02-09 17:41:03.087318367 +0000 +++ /tmp/ghctest-u7xmp5/test spaces/./th/TH_addCStub2.run/TH_addCStub2.comp.stderr.normalised 2017-02-09 17:41:03.087318367 +0000 @@ -1,6 +1,4 @@ TH_addCStub2.hs:13:13: expected ‘;’, ‘,’ or ‘)’ before ‘{’ token - [ "#include " - ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) --- /tmp/ghctest-u7xmp5/test spaces/./th/TH_addCStub2.run/TH_addCStub2.stderr.normalised 2017-02-09 17:41:03.747318367 +0000 +++ /tmp/ghctest-u7xmp5/test spaces/./th/TH_addCStub2.run/TH_addCStub2.comp.stderr.normalised 2017-02-09 17:41:03.751318367 +0000 @@ -1,6 +1,4 @@ TH_addCStub2.hs:13:13: expected ‘;’, ‘,’ or ‘)’ before ‘{’ token - [ "#include " - ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) =====> TH_addCStub2(normal) 4123 of 5714 [0, 0, 0] Any idea what these tests are about? Greetings, Joachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From john_ericson at alumni.brown.edu Thu Feb 9 18:26:20 2017 From: john_ericson at alumni.brown.edu (John Ericson) Date: Thu, 9 Feb 2017 13:26:20 -0500 Subject: Installation failure building GHC targeting 64-bit Android Message-ID: Hello all, I am working on Nixpkgs support for cross-compiling Haskell. GHC finishes building but fails during installation. As far as I can tell, the error seems to be that `make install` fails after it thinks it has installed haddock, looking for the installed one and not finding it. I've attached a build log and the top-level config.log. In a moment I'll push all relevant Nix expressions in case anyone wants to reproduce exactly. Thanks, John (aka Ericson2314 on GitHub; aka Sonarpulse on Freenode) -------------- next part -------------- A non-text attachment was scrubbed... Name: 6hp1n5fl0w571njkv0flkb2jmzsafq-aarch64-unknown-linux-gnu-ghc-8.1.20170106.drv.bz2 Type: application/x-bzip2 Size: 144716 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 671229 bytes Desc: not available URL: From ben at well-typed.com Thu Feb 9 19:12:26 2017 From: ben at well-typed.com (Ben Gamari) Date: Thu, 09 Feb 2017 14:12:26 -0500 Subject: 8.2.1 Status In-Reply-To: References: Message-ID: <87a89vch5x.fsf@ben-laptop.smart-cactus.org> Ryan Scott writes: > Hi Ben, > Hi Ryan, > Sorry for not asking this sooner, but I'd like to merge some form of > https://phabricator.haskell.org/D2961 in time for 8.2 if possible. Sadly, > doing it "the right way" (according to Simon) is proving to be extremely > challenging. A previous iteration of D2961 does work (albeit the code is > not as pretty as it ought to be). > > Are you still planning to cut the 8.2 release tomorrow? If so, I think I'll > revert back to the working version of D2961 and merge that, and leave doing > it the right way as future work. > Indeed I was hoping to and the way things are looking at the moment I believe this plan is still feasible. I would be fine with reverting back to the old version. Perhaps you would like to update the Diff appropriately? 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 john_ericson at alumni.brown.edu Thu Feb 9 20:09:43 2017 From: john_ericson at alumni.brown.edu (John Ericson) Date: Thu, 9 Feb 2017 15:09:43 -0500 Subject: Installation failure building GHC targeting 64-bit Android In-Reply-To: References: Message-ID: There error seems to be on the Nix side of things, after make install. I'll report back once I know for sure. On Thu, Feb 9, 2017 at 1:26 PM, John Ericson wrote: > Hello all, > > I am working on Nixpkgs support for cross-compiling Haskell. GHC > finishes building but fails during installation. As far as I can tell, > the error seems to be that `make install` fails after it thinks it has > installed haddock, looking for the installed one and not finding it. > > I've attached a build log and the top-level config.log. In a moment > I'll push all relevant Nix expressions in case anyone wants to > reproduce exactly. > > Thanks, > > John > > (aka Ericson2314 on GitHub; aka Sonarpulse on Freenode) From ben at well-typed.com Thu Feb 9 23:29:39 2017 From: ben at well-typed.com (Ben Gamari) Date: Thu, 09 Feb 2017 18:29:39 -0500 Subject: Build time over travis time limit again In-Reply-To: References:

Message-ID: <87wpczaqos.fsf@ben-laptop.smart-cactus.org> Andrey Mokhov writes: > Joachim, Ben, > > I gave it a try on my machine. > > First of all, we currently need "--flavour=quick" instead of "quickest" because the latter builds only vanilla RTS. > > If I do: > > ./build.bat -j --flavour=quick > ./build.bat -j --flavour=quick validate > > Then the testsuite completes, but I get a lot of errors, particularly > in "ghci/", "perf/" and "th/". Most of them can probably be fixed > relatively easily in Hadrian, but this requires a good understanding > of which GHC features these tests actually depend on. I'll create an > issue in the Hadrian repo to track down these testsuite failures and > will CC you. > I'm actually not sure it will be so easy for fix some of these. I have seen breakage of the ghci tests in non-validate build configurations (see #13243); this can likely be fixed but it will require some digging as it's not apparent to me what is going wrong. The performance tests will be quite sensitive to optimization level. That being said, perhaps we could make performance testsuite failures non-fatal for the Travis tests. 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 mail at joachim-breitner.de Thu Feb 9 23:43:17 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 09 Feb 2017 18:43:17 -0500 Subject: Build time over travis time limit again In-Reply-To: <87wpczaqos.fsf@ben-laptop.smart-cactus.org> References:

<87wpczaqos.fsf@ben-laptop.smart-cactus.org> Message-ID: <1486683797.17036.0.camel@joachim-breitner.de> Hi, Am Donnerstag, den 09.02.2017, 18:29 -0500 schrieb Ben Gamari: > That being said, perhaps > we could make performance testsuite failures non-fatal for the Travis > tests. they are already disabled: - THREADS=3 SKIP_PERF_TESTS=YES VERBOSE=2 ./validate --fast --quiet Greetings, Joachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ryan.gl.scott at gmail.com Fri Feb 10 15:35:50 2017 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 10 Feb 2017 10:35:50 -0500 Subject: 8.2.1 Status In-Reply-To: <87a89vch5x.fsf@ben-laptop.smart-cactus.org> References: <87a89vch5x.fsf@ben-laptop.smart-cactus.org> Message-ID: Actually, I was able to make "the right way" work after all, thanks to SPJ's help! I'll merge it today (after Harbormaster validates it). Ryan S. On Thu, Feb 9, 2017 at 2:12 PM, Ben Gamari wrote: > Ryan Scott writes: > > > Hi Ben, > > > Hi Ryan, > > > Sorry for not asking this sooner, but I'd like to merge some form of > > https://phabricator.haskell.org/D2961 in time for 8.2 if possible. > Sadly, > > doing it "the right way" (according to Simon) is proving to be extremely > > challenging. A previous iteration of D2961 does work (albeit the code is > > not as pretty as it ought to be). > > > > Are you still planning to cut the 8.2 release tomorrow? If so, I think > I'll > > revert back to the working version of D2961 and merge that, and leave > doing > > it the right way as future work. > > > Indeed I was hoping to and the way things are looking at the moment I > believe this plan is still feasible. I would be fine with reverting back > to the old version. Perhaps you would like to update the Diff > appropriately? > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Feb 10 21:01:43 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 10 Feb 2017 16:01:43 -0500 Subject: Non-wip/* branches Message-ID: <1486760503.14922.1.camel@joachim-breitner.de> Hi, > facundominguez added a comment. > > @nomeata please, could you remove the branches fd/fix-travis and > fd/fix-travis2? Some server hook is preventing me from doing so. turns out I cannot do that either (which I knew). From experience, I know that I can create, force-push and delete branches of the form wip/*, but can only create and fast-forward-push to branches that are not of this form. This is mostly sensible, but it means that I cannot undo an accidental branch creation outside the wip/* branch. Ben, can you delete the two mentioned branches? And more general, would it make sense to prevent common footfolk like me form creating branches outside the wip/* namespace? This ensures that I can always clean up a mess I make. I can still ask some of the super admins, like you, should I for some reason require a branch outside the wip/* namespace. Greetings, Joachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at well-typed.com Fri Feb 10 22:25:54 2017 From: ben at well-typed.com (Ben Gamari) Date: Fri, 10 Feb 2017 17:25:54 -0500 Subject: Non-wip/* branches In-Reply-To: <1486760503.14922.1.camel@joachim-breitner.de> References: <1486760503.14922.1.camel@joachim-breitner.de> Message-ID: <87o9y9bs3x.fsf@ben-laptop.smart-cactus.org> Joachim Breitner writes: > Hi, > >> facundominguez added a comment. >> >> @nomeata please, could you remove the branches fd/fix-travis and >> fd/fix-travis2? Some server hook is preventing me from doing so. > > turns out I cannot do that either (which I knew). From experience, I > know that I can create, force-push and delete branches of the form > wip/*, but can only create and fast-forward-push to branches that are > not of this form. > > This is mostly sensible, but it means that I cannot undo an accidental > branch creation outside the wip/* branch. > > Ben, can you delete the two mentioned branches? > Sure, but I need to run out at the moment so it will take a few hours. Cheers, - Ben > And more general, would it make sense to prevent common footfolk like > me form creating branches outside the wip/* namespace? This ensures > that I can always clean up a mess I make. I can still ask some of the > super admins, like you, should I for some reason require a branch > outside the wip/* namespace. > This sounds like a reasonable proposal to me. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From rwbarton at gmail.com Fri Feb 10 22:55:02 2017 From: rwbarton at gmail.com (Reid Barton) Date: Fri, 10 Feb 2017 17:55:02 -0500 Subject: ghc speed log build script In-Reply-To: References:

Message-ID: Hi Joachim, Is the script used to do the builds for perf.haskell.org/ghc/ available somewhere? I couldn't find it poking around your GitHub repositories. I assume from the line "Try to match validate settings" that the build script creates a custom build.mk or similar. I'd like to know exactly what it does so that I can experiment with custom build settings without worrying about them being overridden by your build script. Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sat Feb 11 01:59:54 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 10 Feb 2017 20:59:54 -0500 Subject: ghc speed log build script In-Reply-To: References:

Message-ID: <1486778394.14922.3.camel@joachim-breitner.de> Hi, they are floating around in various places and once lived in the codespeed repository. I just put them here, slightly easier to find: https://github.com/nomeata/gipeda/tree/master/ghc Greetings, Joachim Am Freitag, den 10.02.2017, 17:55 -0500 schrieb Reid Barton: > Hi Joachim, > > Is the script used to do the builds for perf.haskell.org/ghc/ > available somewhere? I couldn't find it poking around your GitHub > repositories. > > I assume from the line "Try to match validate settings" that the > build script creates a custom build.mk or similar. I'd like to know > exactly what it does so that I can experiment with custom build > settings without worrying about them being overridden by your build > script. > > Regards, > Reid Barton -- Joachim “nomeata” Breitner mail at joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From siddu.druid at gmail.com Sat Feb 11 10:34:11 2017 From: siddu.druid at gmail.com (Siddharth Bhat) Date: Sat, 11 Feb 2017 10:34:11 +0000 Subject: [GHC] #12636: ProfHeap's printf modifiers are incorrect In-Reply-To: <059.f71528e5ca29b823dd918424c3f53d35@haskell.org> References: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> <059.f71528e5ca29b823dd918424c3f53d35@haskell.org> Message-ID: I believe the guarantee at that chunk of code is that void_total of the era will be >= 0. I could add an asset at those sections of code if need be. If not, what is the correct type to be used here? I think size_t is reasonable as none of them are supposed to be negative in the first place. On Sat 11 Feb, 2017, 3:51 PM GHC, wrote: > #12636: ProfHeap's printf modifiers are incorrect > -------------------------------------+------------------------------------- > Reporter: Phyx- | Owner: bollu > Type: bug | Status: new > Priority: normal | Milestone: > Component: Runtime System | Version: 8.0.1 > Resolution: | Keywords: newcomer > Operating System: Windows | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by Phyx-): > > I actually question the use of `ssize_t` at all for these values. I think > the calculations violate the expected value ranges of `ssize_t` namely > with > > {{{ > censuses[t].void_total += size; > censuses[era].void_total -= size; > }}} > > So I think the types in `_counter` are wrong and have the potential to do > an unsigned underflow as `ssize_t` is only guaranteed to be able to store > values between `[-1, {SSIZE_MAX}]`[1] > > [1] > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -- Sending this from my phone, please excuse any typos! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Feb 12 02:37:25 2017 From: ben at well-typed.com (Ben Gamari) Date: Sat, 11 Feb 2017 21:37:25 -0500 Subject: Trac maintenance Message-ID: <878tpcb0d6.fsf@ben-laptop.smart-cactus.org> Hello everyone, I'll be doing some maintenance on the Trac installation in a few minutes. It may be a bit flaky while this happens. Sorry for the inconvenience! 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 Sun Feb 12 02:56:58 2017 From: ben at well-typed.com (Ben Gamari) Date: Sat, 11 Feb 2017 21:56:58 -0500 Subject: Trac maintenance In-Reply-To: <878tpcb0d6.fsf@ben-laptop.smart-cactus.org> References: <878tpcb0d6.fsf@ben-laptop.smart-cactus.org> Message-ID: <8760kgazgl.fsf@ben-laptop.smart-cactus.org> Ben Gamari writes: > Hello everyone, > > I'll be doing some maintenance on the Trac installation in a few > minutes. It may be a bit flaky while this happens. Sorry for the > inconvenience! > Alright, I believe that should do it. We are now running Trac 1.2. Let me know if you encounter any trouble! 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 mail at joachim-breitner.de Sun Feb 12 03:11:32 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 11 Feb 2017 22:11:32 -0500 Subject: Trac maintenance In-Reply-To: <8760kgazgl.fsf@ben-laptop.smart-cactus.org> References: <878tpcb0d6.fsf@ben-laptop.smart-cactus.org> <8760kgazgl.fsf@ben-laptop.smart-cactus.org> Message-ID: <1486869092.31859.0.camel@joachim-breitner.de> Hi, Am Samstag, den 11.02.2017, 21:56 -0500 schrieb Ben Gamari: > Ben Gamari writes: > > > Hello everyone, > > > > I'll be doing some maintenance on the Trac installation in a few > > minutes. It may be a bit flaky while this happens. Sorry for the > > inconvenience! > > > > Alright, I believe that should do it. We are now running Trac 1.2. Let > me know if you encounter any trouble! upon a quick try, I am missing the live preview of changes as I edit a ticket. Oh, and when I try to edit a ticket I get AttributeError: 'Environment' object has no attribute 'get_db_cnx' Greetings, Joachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From matthewtpickering at gmail.com Sun Feb 12 12:01:14 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 12 Feb 2017 12:01:14 +0000 Subject: Trac maintenance In-Reply-To: <8760kgazgl.fsf@ben-laptop.smart-cactus.org> References: <878tpcb0d6.fsf@ben-laptop.smart-cactus.org> <8760kgazgl.fsf@ben-laptop.smart-cactus.org> Message-ID: Were there any particular features that we should know about which motivated the upgrade? Displaying real names is slightly inconvenient now for the purposes of assigning and ccing tickets as you must still use the user names for those fields. Matt On Sun, Feb 12, 2017 at 2:56 AM, Ben Gamari wrote: > Ben Gamari writes: > >> Hello everyone, >> >> I'll be doing some maintenance on the Trac installation in a few >> minutes. It may be a bit flaky while this happens. Sorry for the >> inconvenience! >> > Alright, I believe that should do it. We are now running Trac 1.2. Let > me know if you encounter any trouble! > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From kgadek at gmail.com Sun Feb 12 14:34:24 2017 From: kgadek at gmail.com (=?utf-8?Q?Konrad_G=C4=85dek?=) Date: Sun, 12 Feb 2017 15:34:24 +0100 Subject: Trac maintenance Message-ID: > upon a quick try, I am missing the live preview of changes as I edit a ticket. > > Oh, and when I try to edit a ticket I get > > AttributeError: 'Environment' object has no attribute 'get_db_cnx' I get the same error when I try to create new ticket. -- Konrad Gądek From mail at joachim-breitner.de Sun Feb 12 15:31:40 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 12 Feb 2017 10:31:40 -0500 Subject: Nofib runtimes sensitivity to RTS changes Message-ID: <1486913500.4545.1.camel@joachim-breitner.de> Hi, this is mostly a rant, targeted at the very vague fact that runtime performance benchmarks are so damn hard. This commit just came in: https://git.haskell.org/ghc.git/commitdiff/56c9bb39246f9ffd8ed41a0656bfe8e60d23be57 Clearly, only parts of the profiling RTS have changed. This is what perf.haskell.org measures: https://perf.haskell.org/ghc/#revision/56c9bb39246f9ffd8ed41a0656bfe8e60d23be57 Highlights: nofib/time/cryptarithm1 0.502 + 9.36% 0.549 seconds nofib/time/fasta 0.406 + 4.43% 0.424 seconds These changes are permanent, i.e. the following commits consistently give the higher runtimes. But nofib does not even run the profiling RTS! *very audible sigh* (Conclusion: Ignore runtime changes in nofib when the RTS has changed, the results are simply unusable.) I also wonder if we can adjust the input and parameters to nofib (in a new “veryslow” setting) to get them all run in a few seconds on modern hardware, instead of subseconds. Greetings, Joachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at smart-cactus.org Sun Feb 12 15:33:44 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 12 Feb 2017 10:33:44 -0500 Subject: Trac maintenance In-Reply-To: References: Message-ID: <8737fjbezr.fsf@ben-laptop.smart-cactus.org> Konrad Gądek writes: >> upon a quick try, I am missing the live preview of changes as I edit a ticket. >> >> Oh, and when I try to edit a ticket I get >> >> AttributeError: 'Environment' object has no attribute 'get_db_cnx' > > I get the same error when I try to create new ticket. > Thanks for letting me know. I believe this is now 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 ben at well-typed.com Sun Feb 12 15:39:13 2017 From: ben at well-typed.com (Ben Gamari) Date: Sun, 12 Feb 2017 10:39:13 -0500 Subject: Trac maintenance In-Reply-To: References: <878tpcb0d6.fsf@ben-laptop.smart-cactus.org> <8760kgazgl.fsf@ben-laptop.smart-cactus.org> Message-ID: <87zihra066.fsf@ben-laptop.smart-cactus.org> Matthew Pickering writes: > Were there any particular features that we should know about which > motivated the upgrade? > The primary motivations were to get better spam filtering for user registration and to fix syntax highlighting. > Displaying real names is slightly inconvenient now for the purposes of > assigning and ccing tickets as you must still use the user names for > those fields. > That is true; I'll see what can be done about 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 ben at smart-cactus.org Sun Feb 12 15:56:44 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 12 Feb 2017 10:56:44 -0500 Subject: Nofib runtimes sensitivity to RTS changes In-Reply-To: <1486913500.4545.1.camel@joachim-breitner.de> References: <1486913500.4545.1.camel@joachim-breitner.de> Message-ID: <87wpcv9zcz.fsf@ben-laptop.smart-cactus.org> Joachim Breitner writes: > Hi, > > this is mostly a rant, targeted at the very vague fact that runtime > performance benchmarks are so damn hard. > > This commit just came in: > https://git.haskell.org/ghc.git/commitdiff/56c9bb39246f9ffd8ed41a0656bfe8e60d23be57 > Clearly, only parts of the profiling RTS have changed. > > This is what perf.haskell.org measures: > https://perf.haskell.org/ghc/#revision/56c9bb39246f9ffd8ed41a0656bfe8e60d23be57 > Highlights: > nofib/time/cryptarithm1 0.502 + 9.36% 0.549 seconds > nofib/time/fasta 0.406 + 4.43% 0.424 seconds > These changes are permanent, i.e. the following commits consistently > give the higher runtimes. > > But nofib does not even run the profiling RTS! > > *very audible sigh* > > (Conclusion: Ignore runtime changes in nofib when the RTS has changed, > the results are simply unusable.) > > I also wonder if we can adjust the input and parameters to nofib (in a > new “veryslow” setting) to get them all run in a few seconds on modern > hardware, instead of subseconds. I think this would be a very worthwhile effort. Sub-second runtimes really are just plain useless. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Sun Feb 12 17:25:56 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 12 Feb 2017 12:25:56 -0500 Subject: Convincing GHC not to produce unfoldings during simplification Message-ID: <87tw7z9v8b.fsf@ben-laptop.smart-cactus.org> I'm currently trying to get the interface file bulk imposed by TTypeable down. The branch will currently produce two top-level bindings for each TyCon. For instance, given the type, data Proxy (a :: k) = Proxy the branch will produce (ignoring the promoted datacon for a moment), $tcProxy :: TyCon $tcProxy = GHC.Types.TyCon fpr1 fpr2 -- fingerprints $trModule (GHC.Types.TrNameS "Proxy"#) 1 krep_aebr krep_aebr :: KindRep krep_aebr [InlPrag=NOINLINE CONLIKE] = GHC.Types.KindRepFun (GHC.Types.KindRepVar 0) (GHC.Types.KindRepTYPE GHC.Types.LiftedRep) Note that the KindRep has been marked as NOINLINE; I do this intentionally as these things can grow quite large (consider, for instance, the kind of a promoted tuple constructor). This is especially true as the simplifier tends to float out the constituents of the KindRep. After the first simplifier phase we end up with, krep_sebQ :: GHC.Types.KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 30 0}] krep_sebQ = GHC.Types.$WKindRepVar (GHC.Types.I# 0#) krep_sebR :: GHC.Types.KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] krep_sebR = GHC.Types.$WKindRepTYPE GHC.Types.LiftedRep krep_aebr [InlPrag=NOINLINE CONLIKE] :: GHC.Types.KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] krep_aebr = GHC.Types.KindRepFun krep_sebQ krep_sebR This means that GHC will now include each of the bindings floated out from krep_aebr in the interface file, despite the NOINLINE pragma, as they are all depended upon by the exported $tcProxy through their unfoldings. This is Quite Bad. I have observed that the floated bindings are not included in the interface file with -O0. Moreover, the core2core output clearly shows the unfoldings being added after the first simplifier phase. I haven't yet determined where in the simplifier these unfoldings are being introduced, but if anyone has ideas I'd love to hear them. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Sun Feb 12 17:48:21 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 12 Feb 2017 12:48:21 -0500 Subject: Convincing GHC not to produce unfoldings during simplification In-Reply-To: <87tw7z9v8b.fsf@ben-laptop.smart-cactus.org> References: <87tw7z9v8b.fsf@ben-laptop.smart-cactus.org> Message-ID: <87poin9u6y.fsf@ben-laptop.smart-cactus.org> Ben Gamari writes: > I have observed that the floated bindings are not included in the > interface file with -O0. Moreover, the core2core output clearly shows > the unfoldings being added after the first simplifier phase. I haven't > yet determined where in the simplifier these unfoldings are being > introduced, but if anyone has ideas I'd love to hear them. > Ahhh, the inline pragma I was applying was wrong; I wanted neverInlinePragma but instead rolled my own (incorrect) version of it. It's interesting that neverInlinePragma has a NeverActive activation with EmptyInlineSpec. My intuition had lead me to an AlwaysActive activation of a NoInline InlineSpec. 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 Sun Feb 12 18:09:57 2017 From: ben at well-typed.com (Ben Gamari) Date: Sun, 12 Feb 2017 13:09:57 -0500 Subject: Trac maintenance In-Reply-To: <87zihra066.fsf@ben-laptop.smart-cactus.org> References: <878tpcb0d6.fsf@ben-laptop.smart-cactus.org> <8760kgazgl.fsf@ben-laptop.smart-cactus.org> <87zihra066.fsf@ben-laptop.smart-cactus.org> Message-ID: <87mvdr9t6y.fsf@ben-laptop.smart-cactus.org> Ben Gamari writes: > Matthew Pickering writes: > >> Were there any particular features that we should know about which >> motivated the upgrade? >> > The primary motivations were to get better spam filtering for user > registration and to fix syntax highlighting. > >> Displaying real names is slightly inconvenient now for the purposes of >> assigning and ccing tickets as you must still use the user names for >> those fields. >> > That is true; I'll see what can be done about this. > I have disabled display of full names. For future reference, the change is documented here[1]. Cheers, - Ben [1] https://trac.edgewall.org/ticket/7339 -------------- 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 12 22:57:18 2017 From: ben at well-typed.com (Ben Gamari) Date: Sun, 12 Feb 2017 17:57:18 -0500 Subject: Improving trac notifications In-Reply-To: References: <87twn297mm.fsf@smart-cactus.org> <874meq8s53.fsf@smart-cactus.org>

Message-ID: <87h93z9fw1.fsf@ben-laptop.smart-cactus.org> Matthew Pickering writes: > I attach a patch which should improve the notifications. > I have applied this patch to our Trac 1.2 installation. 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 matthewtpickering at gmail.com Sun Feb 12 23:04:16 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 12 Feb 2017 23:04:16 +0000 Subject: Improving trac notifications In-Reply-To: <87h93z9fw1.fsf@ben-laptop.smart-cactus.org> References: <87twn297mm.fsf@smart-cactus.org> <874meq8s53.fsf@smart-cactus.org>