7.10.1RC2 compile problem? ghc: internal error: PAP object entered!
Maybe this is something I shouldn't be doing, but I thought it was worth mentioning in case I have found a compiler bug. Should I file a bug for this? cabal install *--allow-newer=base* accelerate ... [10 of 10] Compiling Data.Label.Base ( src/Data/Label/Base.hs, dist/build/Data/Label/Base.o ) ghc: internal error: PAP object entered! (GHC version 7.10.0.20150123 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Restricted Template Haskell
On Fri, Jan 30, 2015 at 7:05 PM, adam vogt vogt.a...@gmail.com wrote: Hi Greg, Perhaps a less-invasive way to implement the -XSafe part of your proposal would be to provide a module like: module Language.Haskell.TH.Safe ( module Language.Haskell.TH, reifyWithoutNameG, ) where import Language.Haskell.TH hiding (runIO, reify*) where reifyWithoutNameG is the same as reify, except definitions that are out of scope are either missing or modified such that they use NameQ instead of NameG for out-of-scope names. Thanks, I added this concept to the wiki. That way there is no new syntax needed, and safe TH can be called by unsafe TH without any conversions. I think defining another monad like Q that can do less is too inconvenient because you have to disambiguate between Safe.listE and Unsafe.listE, or make those functions more polymorphic (which makes type errors worse). Another option would be if there were Oh, you are getting into more concrete details now than I have even thought about! For the restricted monad route, we might look into a more capable method of using capabilities that would end up looking like this: reify :: Name - Restrict (TH :+: Reify) Info runIO :: IO a - Restrict (TH :+: RunIO) a There are still a lot of details to work out, thanks for getting things started. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.10.1RC2 compile problem? ghc: internal error: PAP object entered!
On 2015-01-31 at 14:34:35 +0100, George Colpitts wrote: Maybe this is something I shouldn't be doing, but I thought it was worth mentioning in case I have found a compiler bug. Should I file a bug for this? cabal install *--allow-newer=base* accelerate ... [10 of 10] Compiling Data.Label.Base ( src/Data/Label/Base.hs, dist/build/Data/Label/Base.o ) ghc: internal error: PAP object entered! (GHC version 7.10.0.20150123 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I suspect this has to do with `--allow-newer=base` allowing template-haskell-2.9.0.0 to be re-installed (which then becomes a build-dependency of `fclabels`). GHC 7.10, however, comes with template-haskell-2.10.0.0 e.g. try the following in an empty sandbox: cabal install fclabels --allow-newer=base --constraint 'template-haskell == 2.9.*' (wheares a plain `cabal install fclabels` in a fresh sandbox should succeed w/o panics with GHC 7.10) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.10.1RC2 compile problem? ghc: internal error: PAP object entered!
On Sat, Jan 31, 2015 at 11:09 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: On 2015-01-31 at 14:34:35 +0100, George Colpitts wrote: Maybe this is something I shouldn't be doing, but I thought it was worth mentioning in case I have found a compiler bug. Should I file a bug for this? cabal install *--allow-newer=base* accelerate ... [10 of 10] Compiling Data.Label.Base ( src/Data/Label/Base.hs, dist/build/Data/Label/Base.o ) ghc: internal error: PAP object entered! (GHC version 7.10.0.20150123 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I suspect this has to do with `--allow-newer=base` allowing template-haskell-2.9.0.0 to be re-installed (which then becomes a build-dependency of `fclabels`). GHC 7.10, however, comes with template-haskell-2.10.0.0 Ah yes, you're exactly right. I didn't encounter this when I tried to reproduce the issue because I have a bunch of lines like constraint: template-haskell installed in my .cabal/config file. Regards, Reid Barton ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Delaying 7.10?
A safety issue of that magnitude is a valid reason to hold up a release at the last minute IMHO. Manuel Simon Peyton Jones simo...@microsoft.com: Friends In a call with a bunch of type hackers, we were discussing https://ghc.haskell.org/trac/ghc/ticket/9858 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 mailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
