Re: Delaying 7.10?
I'm worried about the code-size regression. We should definitely measure how bad it is before making a decision on whether to enable Typeable by default. +1 to delaying the release. Cheers, Simon On 29/01/2015 17:58, Simon Peyton Jones wrote: Friends In a call with a bunch of type hackers, we were discussing https://ghc.haskell.org/trac/ghc/ticket/9858 This is a pretty serious bug. It allows a malicious person to construct his own unsafeCoerce, and so completely subverts Safe Haskell. Actually there are two bugs (see comment:19). The first is easily fixed. But the second is not. We explored various quick fixes, but the real solution is not far out of reach. It amounts to this: ·Every data type is automatically in Typeable. No need to say “deriving(Typeable)” or “AutoDeriveTypeable” (which would become deprecated) ·In implementation terms, the constraint solver treats Typeable specially, much as it already treats Coercible specially. It’s not a huge job. It’d probably take a couple of days of implementation work, and some time for shaking out bugs and consequential changes. The biggest thing might be simply working out implementation design choices. (For example, there is a modest code-size cost to making everything Typeable, esp because that includes the data constructors of the type (which can be used in types, with DataKinds). Does that matter? Should we provide a way to suppress it? If so, we’d also need a way to express whether or not the Typable instance exists in the interface file.) But it is a substantial change that will touch a lot of lines of code. Moreover, someone has to do it, and Iavor (who heroically volunteered) happens to be travelling next week. So it’s really not the kind of thing we would usually do after RC2. But (a) it’s serious and, as it happens, (b) there is also the BBP Prelude debate going on. Hence the question: should we simply delay 7.10 by, say, a month? After all, the timetable is up to us. Doing so might give a bit more breathing space to the BBP debate, which might allow time for reflection and/or implementation of modest features to help the transition. (I know that several are under discussion.) Plus, anyone waiting for 7.10 can simply use RC2, which is pretty good. Would that be a relief to the BBP debate? Or any other opinions. Simon PS: I know, I know: there is endless pressure to delay releases to get stuff in. If we give in to that pressure, we never make a release. But we should know when to break our own rules. Perhaps this is such an occasion. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Restricted Template Haskell
Hello GHC friends! I am starting up a proposal for variants of Template Haskell that restrict what operations are available. The goal is to make TH easier for users to reason about and to allow for an easier compilation story. Here is the proposal page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted Right now the proposal does not have any details and the goal is to write out a clear specification. If this sounds interesting to you, let me know or leave some feedback on the wiki. Thanks, Greg Weber ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
integer-gmp-1.0.0.0 ?
Hi devs, I've just hit on a strange bug, and I don't know where to start looking. In my branch where I'm building support for dependent types (github.com/goldfirere/ghc.git; branch: nokinds but you don't need to look there) I'm going through the testsuite and picking off bugs one at a time. I'm very puzzled by the output I'm getting from typecheck/should_compile/tc231, which does a -ddump-tc. At the end, I see ... Dependent modules: [] Dependent packages: [base-4.8.0.0, ghc-prim-0.3.1.0, integer-gmp-1.0.0.0] Notice the version number of integer-gmp. I haven't touched anything near there! And, my integer-gmp.cabal file says 0.5.1.0, which is what I'd expect. Sure enough, when I use the inplace `ghc-pkg list`, I see that I have integer-gmp-1.0.0.0 installed, along with all the other boot packages with their correct version numbers. Any hints here? I can surely work around this, but it's very strange! Thanks! Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Make one-shot a per-registration property
Herbert Valerio Riedel h...@gnu.org writes: On 2015-01-30 at 05:36:21 +0100, Austin Seipp wrote: You won't have permissions to push it to 7.10. I can try to get to it soon, but I make no guarantees until next week (out of town atm). CC Herbert, who can probably get to it more promptly than I can. I'll look into it later today Thanks Herbert! ...for the future: Please set the respective Trac tickets to which a commit belongs into the 'fixed in HEAD, please merge to STABLE'-ticket-state, as well as setting the proper milestone-value. That makes sure we don't miss it when preparing releases. Hmm, alright. In this case I only opened a Differential so there was no Trac ticket to flag; I'll open a ticket in the future to ensure that things don't slip through the cracks. Thanks, - Ben pgpUSEhsgv4GC.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Make one-shot a per-registration property
On 2015-01-30 at 05:36:21 +0100, Austin Seipp wrote: You won't have permissions to push it to 7.10. I can try to get to it soon, but I make no guarantees until next week (out of town atm). CC Herbert, who can probably get to it more promptly than I can. I'll look into it later today ...for the future: Please set the respective Trac tickets to which a commit belongs into the 'fixed in HEAD, please merge to STABLE'-ticket-state, as well as setting the proper milestone-value. That makes sure we don't miss it when preparing releases. Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
76-fold regression GHC 7.10-7.11 in T9961 byte-allocation
Hello *, I noticed something odd while validating the GHC 7.10 branch: bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) ExpectedT9961(normal) bytes allocated: 772510192 +/-5% Lower bound T9961(normal) bytes allocated: 733884682 Upper bound T9961(normal) bytes allocated: 811135702 Actual T9961(normal) bytes allocated: 9766160 Deviation T9961(normal) bytes allocated: -98.7 % *** unexpected stat test failure for T9961(normal) ...then I also ran ./validate against today's GHC HEAD, and re-ran the T9961 test: ExpectedT9961(normal) bytes allocated: 772510192 +/-5% Lower bound T9961(normal) bytes allocated: 733884682 Upper bound T9961(normal) bytes allocated: 811135702 Actual T9961(normal) bytes allocated: 748225848 Deviation T9961(normal) bytes allocated: -3.1 % I'm not sure if it's just the test-case being broken, or there's something real regression between 7.10 and HEAD... However, I don't have time to investigate this. Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
