- ghc-devs - Haskell.org

Re: [commit: ghc] master: Revert "Per-thread allocation counters and limits" (f0fcc41)
by Karel Gardas 13 May '14

13 May '14

Hello Simon, I'm sorry to disturb you, but I've noticed that your revert patch below contains this change: diff --git a/includes/CodeGen.Platform.hs b/includes/CodeGen.Platform.hs index f3abb3d..3d6dd41 100644 --- a/includes/CodeGen.Platform.hs +++ b/includes/CodeGen.Platform.hs @@ -741,8 +741,10 @@ globalRegMaybe CurrentTSO = Just (RealRegSingle REG_CurrentTSO) # ifdef REG_CurrentNursery globalRegMaybe CurrentNursery = Just (RealRegSingle REG_CurrentNursery) # endif -#endif globalRegMaybe _ = Nothing +#else +globalRegMaybe = panic "globalRegMaybe not defined for this platform" +#endif and I'm not sure if this is intentional or just overlooked addition. The problem with this line is that it causes stage1 panic on unregisterised build on PPC64 platform: http://haskell.inf.elte.hu/builders/linux-ppc64-head/41/10.html and we have not had such panic before the patch: http://haskell.inf.elte.hu/builders/linux-ppc64-head/31/10.html -- well, you see that dll-split segfaults, but at least ghc-stage1 is proved to work well here. Kudos to Gabor Pali who spotted this on PPC64 builder... Thanks! Karel On 05/ 4/14 11:45 PM, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/f0fcc41d755876a1b02d1c7c79f575150… > >> --------------------------------------------------------------- > > commit f0fcc41d755876a1b02d1c7c79f57515059f6417 > Author: Simon Marlow<marlowsd(a)gmail.com> > Date: Sun May 4 20:27:42 2014 +0100 > > Revert "Per-thread allocation counters and limits" > > Problems were found on 32-bit platforms, I'll commit again when I have a fix. > > This reverts the following commits: > 54b31f744848da872c7c6366dea840748e01b5cf > b0534f78a73f972e279eed4447a5687bd6a8308e > > >> --------------------------------------------------------------- > > f0fcc41d755876a1b02d1c7c79f57515059f6417 > compiler/cmm/CmmLayoutStack.hs | 9 +- > compiler/codeGen/StgCmmForeign.hs | 268 ++++++--------------- > includes/CodeGen.Platform.hs | 4 +- > includes/rts/Constants.h | 6 - > includes/rts/Flags.h | 8 - > includes/rts/Threads.h | 8 +- > includes/rts/storage/TSO.h | 31 +-- > libraries/base/Control/Exception.hs | 1 - > libraries/base/Control/Exception/Base.hs | 1 - > libraries/base/GHC/Conc.lhs | 6 - > libraries/base/GHC/Conc/Sync.lhs | 92 +------ > libraries/base/GHC/IO/Exception.hs | 21 +- > rts/HeapStackCheck.cmm | 4 +- > rts/Linker.c | 4 - > rts/Prelude.h | 2 - > rts/RaiseAsync.c | 54 ----- > rts/RaiseAsync.h | 4 - > rts/RtsFlags.c | 10 - > rts/RtsStartup.c | 1 - > rts/Schedule.c | 19 -- > rts/Threads.c | 77 +++--- > rts/package.conf.in | 2 - > rts/sm/Storage.c | 6 - > rts/win32/libHSbase.def | 1 - > testsuite/tests/concurrent/should_run/all.T | 7 - > .../tests/concurrent/should_run/allocLimit1.hs | 9 - > .../tests/concurrent/should_run/allocLimit1.stderr | 1 - > .../tests/concurrent/should_run/allocLimit2.hs | 17 -- > .../tests/concurrent/should_run/allocLimit3.hs | 15 -- > .../tests/concurrent/should_run/allocLimit3.stderr | 1 - > .../tests/concurrent/should_run/allocLimit3.stdout | 1 - > .../tests/concurrent/should_run/allocLimit4.hs | 31 --- > utils/deriveConstants/DeriveConstants.hs | 1 - > 33 files changed, 144 insertions(+), 578 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc f0fcc41d755876a1b02d1c7c79f57515059f6417 > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

3 3

Loading package integer-gmp ... <command line>: can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory)
by Mateusz Kowalczyk 12 May '14

12 May '14

Hi, Trying to compile GHC in the source tree on NixOS and meeting with failure with: "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build -dynamic-too -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o -dyno libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.dyn_o Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... <command line>: can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory) While libgmp isn't anywhere obvious, below is my build.mk and content of the pointed-to directories. Am I missing something here? Is something ignoring the configure option maybe? [shana@lenalee:~/programming/ghc/mk]$ cat build.mk libraries/integer-gmp_CONFIGURE_OPTS += --configure-option=--with-gmp-libraries=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib libraries/integer-gmp_CONFIGURE_OPTS += --configure-option=--with-gmp-includes=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/include DYNAMIC_BY_DEFAULT = NO [shana@lenalee:~/programming/ghc/mk]$ l /nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib total 604K dr-xr-xr-x 2 root nixbld 4.0K Jan 1 1970 . dr-xr-xr-x 5 root nixbld 4.0K Jan 1 1970 .. -r-xr-xr-x 1 root nixbld 949 Jan 1 1970 libgmp.la lrwxrwxrwx 1 root nixbld 16 Jan 1 1970 libgmp.so -> libgmp.so.10.1.3 lrwxrwxrwx 1 root nixbld 16 Jan 1 1970 libgmp.so.10 -> libgmp.so.10.1.3 -r-xr-xr-x 1 root nixbld 556K Jan 1 1970 libgmp.so.10.1.3 -r-xr-xr-x 1 root nixbld 1.1K Jan 1 1970 libgmpxx.la lrwxrwxrwx 1 root nixbld 17 Jan 1 1970 libgmpxx.so -> libgmpxx.so.4.3.3 lrwxrwxrwx 1 root nixbld 17 Jan 1 1970 libgmpxx.so.4 -> libgmpxx.so.4.3.3 -r-xr-xr-x 1 root nixbld 30K Jan 1 1970 libgmpxx.so.4.3.3 [shana@lenalee:~/programming/ghc/mk]$ l /nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/include total 204K dr-xr-xr-x 2 root nixbld 4.0K Jan 1 1970 . dr-xr-xr-x 5 root nixbld 4.0K Jan 1 1970 .. -r--r--r-- 1 root nixbld 78K Jan 1 1970 gmp.h -r--r--r-- 1 root nixbld 114K Jan 1 1970 gmpxx.h -- Mateusz K.

2 10

Fwd: Question about Roles and the AMP work
by Benno Fünfstück 12 May '14

12 May '14

I'm not familar with the internals of GHC, but maybe it would be possible for GHC to just use the default definition for `join` in the case that deriving fails because of roles? At least if the class to be derived has a `MINIMAL` pragma, GHC could check if that is still satisfied even without the method that failed to derive, and use the default definition if that's the case. 2014-05-12 17:28 GMT+02:00 Edward Kmett <ekmett(a)gmail.com>: As a straw man, if we went to a typeclass-driven 'next arg is > representational' approach then we could possibly recover 'join' here. > > e.g. > > class Representational f where > rep :: Coercion f g -> Coercion a b -> Coercion (f a) (g b) > > class Representational f => Phantom f where > phantom :: Coercion f g -> Coercion (f a) (g b) > > When we look at for the constraint head Coercible (f a) (g b) we'd then > check for Phantom f and if so look for Coercible f g, or fall back to Representational > f, and look for Coercible f g and Coercible a b. > > Then to derive GND for C m it'd need to check Representational m due to > the type of join needing m's next arg to be representational, find it and > move on. > > The set of these instances can be left open like any other typeclass and > users could supply their own for tricky conversions if need be. > > If you just wrote the existing role annotations, but let them request > currently impossible roles you could use the desired role to infer the > constraints involved. > > e.g. > > newtype StateT s m a = StateT { runStateT :: s -> m (a, s) } > > should be able to derive something like > > instance Representational (StateT s) > instance Representational m => Representational (StateT s m) > instance Phantom m => Phantom (StateT s m) > > If we put nominal or representational on the m argument > > type role StateT nominal nominal nominal > > then we could just elide the instances for anything lower in the nominal > -> representational -> phantom lattice than the named role. > > The positional argument scheme isn't perfect, as in the above it'd fail to > let you derive `instance Representational StateT` due to the s occurring > under m, an argument later in the argument list, but it does fix most of > the problems with Coercible and monad transfomers. > > There might be some fancier form that can cover all of the use cases, but > I'm not seeing it off hand. > > -Edward > > > On Tue, May 13, 2014 at 12:59 AM, Simon Peyton Jones < > simonpj(a)microsoft.com> wrote: > >> This looks a bit awkward to me. Here's a small test case >> >> class C m where >> ret :: a -> m a >> bind :: m a -> (a -> m b) -> m b >> join :: m (m a) -> m a >> >> newtype T m a = MkT (m a) deriving( C ) >> >> This is accepted without the 'join' in the class, but rejected with it. >> >> So *all* uses of GND to do 'deriving( Monad )' will break when 'join' is >> added to Monad. >> >> And this is because we don't know that 'm' ranges only over things that >> have representational arguments; type variables always have nominal >> arguments. The paper draws attention to this shortcoming, but now it's >> becoming important. >> >> I can't think of an obvious workaround either, except not putting 'join' >> in Monad. >> >> Simon >> >> >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of >> Austin >> | Seipp >> | Sent: 12 May 2014 13:53 >> | To: ghc-devs(a)haskell.org >> | Subject: Question about Roles and the AMP work >> | >> | Hello all, >> | >> | While picking the AMP patch back up, it is almost ready to go, but I got >> | quite a puzzling error when attempting to build 'haskeline' with the AMP >> | changes. I don't seem to remember encountering this error before - but >> | maybe my mind is hazy. >> | >> | The error in question is this: >> | >> | https://gist.github.com/thoughtpolice/6df4c70d8a8fb711b282 >> | >> | The TL;DR is that the move of `join` into base has caused a problem >> | here. The error really speaks for itself: GND tries to derive an >> | instance of `join` for DumbTerm, which would have the type >> | >> | join :: DumbTerm m (DumbTerm m a) -> DumbTerm m a >> | >> | and be equivalent to join for StateT. But this can't hold: DumbTerm >> | should unwrap directly to StateT (by newtype equality) and thus the >> | third parameter to StateT in this case is `DumbTerm m a` if you expand >> | the types - but because this argument is Nominal, it cannot unify with >> | 'PosixT m', which is the actual definition of DumbTerm in the first >> | place! >> | >> | With a little thought, this error actually seems reasonable. But it >> | puzzles me as to what we should do now. One thing we could do is just >> | write the instances manually, of course. But that's a bit annoying. >> | >> | Another alternative (and also unfortunate) change is to leave `join` out >> | of Monad, in which case the GND mechanism is oblivious to it and does >> | not need to worry about deriving these cases. >> | >> | I am not sure how many packages depend on using GND to derive monads >> | like StateT with Nominal arguments, but I imagine it is not totally >> | insignificant and will essentially hurt a lot of people who may use it. >> | >> | Richard, I'm particularly interested to hear what you think. This one >> | sort of snuck up! >> | >> | (NB: despite this, the AMP work is very close to landing in HEAD, at >> | which point we can begin cleaning stuff up faster.) >> | >> | -- >> | Regards, >> | >> | Austin Seipp, Haskell Consultant >> | Well-Typed LLP, http://www.well-typed.com/ >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs(a)haskell.org >> | http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > >

1 0

Why is an irrefutable pattern desugared to a 'cast', while an incomplete pattern is not?
by Christiaan Baaij 12 May '14

12 May '14

Dear list, When I ask for the desugaring of: > module PatError where > > paterror :: Maybe Int -> Int > paterror (Just i) = i I get the following: > PatError.paterror = > \ (ds_dIS :: Data.Maybe.Maybe GHC.Types.Int) -> > break<1>() > case ds_dIS of _ [Occ=Dead] { > __DEFAULT -> > (\ _ [Occ=Dead, OS=OneShot] -> > Control.Exception.Base.patError > @ GHC.Types.Int "PatError.hs:4:1-21|function paterror"#) > GHC.Prim.void#; > Data.Maybe.Just i_aqG -> break<0>(i_aqG) i_aqG > } Where 'Control.Exception.Base.patError' is applied to 'Int'. However, when I compile the almost identical code with an irrefutable pattern: > module PatError2 where > > patError :: Maybe Int -> Int > patError ~(Just i) = i I get the following core: > PatError2.paterror = > \ (ds_dIT :: Data.Maybe.Maybe GHC.Types.Int) -> > break<1>() > let { > i_aqG :: GHC.Types.Int > [LclId, Str=DmdType] > i_aqG = > case ds_dIT of _ [Occ=Dead] { > __DEFAULT -> > (\ _ [Occ=Dead, OS=OneShot] -> > (Control.Exception.Base.irrefutPatError > @ () "PatError2.hs:4:1-22|(Data.Maybe.Just i)"#) > `cast` (UnivCo representational () GHC.Types.Int > :: () ~# GHC.Types.Int)) > GHC.Prim.void#; > Data.Maybe.Just i_aqG -> i_aqG > } } in > break<0>(i_aqG) i_aqG Where 'Control.Exception.Base.patError' is first applied to '()' after which it is casted to 'GHC.Types.Int'. Out of the [note] for the 'UnivCo' coercion: > The UnivCo ("universal coercion") serves two rather separate functions: > - the implementation for unsafeCoerce# > - placeholder for phantom parameters in a TyConAppCo It seems to be used in the 'unsafeCoerce#' role here. My question is: why can't the irrefutable pattern be translated to 'Control.Exception.Base.irrefutPatError' applied to 'Int'? Instead of using this 'cast'? I find the cast-less version much more readable. Greetings, Christiaan

2 1

How to fix T5979?
by Joachim Breitner 10 May '14

10 May '14

Hi, SPJ recently committed: commit 12332f1add3eb9615a62abb36898819b2e67e865 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Thu May 8 13:06:05 2014 +0100 Error message wibble, presumably due to recent changes in transformers diff --git a/testsuite/tests/ghci/scripts/T5979.stderr b/testsuite/tests/ghci/scripts/T5979.stderr index fe6e012..7230011 100644 --- a/testsuite/tests/ghci/scripts/T5979.stderr +++ b/testsuite/tests/ghci/scripts/T5979.stderr @@ -1,4 +1,4 @@ <no location info>: Could not find module ‘Control.Monad.Trans.State’ - It is not a module in the current program, or in any known package. + It is a member of the hidden package ‘transformers-0.3.0.0’. But that breaks when transformers is indeed not installed (as it is the case in a minimal validation run such as on travis): Actual stderr output differs from expected: --- ./ghci/scripts/T5979.stderr 2014-05-10 03:10:07.860423047 +0000 +++ ./ghci/scripts/T5979.run.stderr 2014-05-10 03:32:54.861642002 +0000 @@ -1,4 +1,4 @@ <no location info>: Could not find module ‘Control.Monad.Trans.State’ - It is a member of the hidden package ‘transformers-0.3.0.0’. + It is not a module in the current program, or in any known package. *** unexpected failure for T5979(ghci) For now I added a reqlib('transformers') to the test, hoping that that helps. But why should the error message mention "transformers" at all when the package import is actually explicit to import "nonexisting"? $ cat T5979.script :set -XPackageImports import "nonexisting" Control.Monad.Trans.State import "transformers" Control.Monad.Trans.State import "transformers" Control.Monad.Trans.Reader I am a bit worried that there is a regression here and SPJs commit just hides it. But gotta run now and cannot investigate further. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

3 4

Bugsquashing at ZuriHac
by Joachim Breitner 10 May '14

10 May '14

Dear fellow deverlopers, I’ll be attending ZuriHac in a month time, without a project of my own that I plan to pursue. Hence I’m considering to run a “GHC bug squashing” project there. Besides getting bugs squashed, this should hopefully attract new contributors and allow us to teach them the ropes and tricks and the need for notes efficiently by shoulder-surfing and face-to-face discussions. Who of you is going to attend ZuriHac as well and will want to join me in managing this project? Also, this means its a good time to start tagging tickets as suitable for beginners. I know we have a list somewhere, but googling for "ghc easy tickets" does not find it... but clicking through the wiki I find https://ghc.haskell.org/trac/ghc/wiki/Newcomers#Fixingabug which is unfortunately quite small. I’ll also look for tickets of difficulty easy and moderate. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

5 5

cgrun051
by Simon Peyton Jones 10 May '14

10 May '14

I'm getting Unexpected failures: . cgrun051 [bad exit code] (normal,hpc,optasm,profasm,ghci,threaded1,threaded2,dyn,profthreaded,optllvm,g1) =====> cgrun051(optasm) 46 of 98 [0, 2, 0] cd . && '/5playpen/simonpj/HEAD-2/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o cgrun051 cgrun051.hs -O -fasm >cgrun051.comp.stderr 2>&1 cd . && ./cgrun051 </dev/null >cgrun051.run.stdout 2>cgrun051.run.stderr Wrong exit code (expected 0 , actual 1 ) cgrun051 throws an exception, so presumably should have exit code 1. And it does. But the test seems to test for exit code 0. Why does the test check for 0 not 1? And what has changed? This is HEAD. I don't have a virgin head right now, but I don't think any of my changes could cause this. I am also seeing the ffi/should_compile cc004 [stderr mismatch] (normal) errors that Joachim reported. It'd be great if someone could fix that, whatever it is. SImon

3 2

GHC status report
by Simon Peyton Jones 09 May '14

09 May '14

As Austin has told us, there's a draft of the GHC Status Report for the HCAR, here: https://ghc.haskell.org/trac/ghc/wiki/Status/May14 Have we missed out something you have been working hard on? Do take a moment to add a bullet in an appropriate place (it's a wiki). I'd like to be sure that we are giving credit to all the appropriate people, so please help us fix that too. GHC is a team effort. Deadline is 1 May I think. Thanks Simon

10 40

GHC not parsing TH pretty printed code
by George Roldugin 09 May '14

09 May '14

Hi all, I've hit a problem with GHC 7.8 where the code pretty printed by Template Haskell fails to parse. The problem is with the placement of explicit semicolons in place of indentation. The following code pretty printed by TH won't parse: bar = do {let x = 5; return x} GHC expects the following placement of semicolons: bar = do {let x = 5 ; return x} I reported this bug and included sample TH code to reproduce the problem here: https://ghc.haskell.org/trac/ghc/ticket/9022 I rely on compiling code constructed with TH for my thesis project. Is there a work around I could use besides going back to GHC 7.6? Cheers, George

3 2

Simplifying casts and beta-reduction
by Conal Elliott 08 May '14

08 May '14

I'm looking for tools to help simplify Core terms that involve casts. In particular, I want to beta-reduce when the function is wrapped with a cast. Do the GHC sources have such utility functions? Here is an example of a lambda expression with a cast. In context, it's applied to two type arguments and two dictionary arguments and returns a function of one more argument. (The function `(-->)` is defined as `(f --> h) g = h . g . f`.) > ((\ (@ a8) (@ b) > ($dEncodable :: Encodable a8) > ($dEncodable1 :: Encodable b) -> > case $dEncodable of _ > D:Encodable _ tpl_B3 -> > case $dEncodable1 of _ > D:Encodable tpl_B2 _ -> > \ (g :: a8 -> b) (eta :: Encode a8) -> tpl_B2 (g (tpl_B3 eta)) > ) > `cast` (forall a8 b. > <Encodable a8>_R > -> <Encodable b>_R > -> <a8 -> b>_R > -> Sub (Sym (TFCo:R:Encode(->)[0] <a8>_N <b>_N)) > :: (forall a8 b. (Encodable a8, Encodable b) => > (a8 -> b) -> Encode a8 -> Encode b) > ~# > (forall a8 b. (Encodable a8, Encodable b) => > (a8 -> b) -> Encode (a8 -> b)))) I can imagine pushing the `cast` down through the type lambdas while stripping off `forall` coercions, then pushing the remaining `cast` through the dictionary arguments, while stripping off the outer `<Encodable t>_R ->` coercion wrappers, and then pushing the cast into the `case` alternatives and the lambda body, leaving something like > (\ (@ a8) (@ b) > ($dEncodable :: Encodable a8) > ($dEncodable1 :: Encodable b) -> > case $dEncodable of _ > D:Encodable _ tpl_B3 -> > case $dEncodable1 of _ > D:Encodable tpl_B2 _ -> > \ (g :: a8 -> b) -> > (\ (eta :: Encode a8) -> tpl_B2 (g (tpl_B3 eta))) > `cast` (Sub (Sym (TFCo:R:Encode(->)[0] <a8>_N <b>_N)) > :: (Encode a8 -> Encode b) > ~# > (Encode (a8 -> b)))) Now, given type, dictionary, and function arguments, I think we could beta-reduce. Before I try implementing these transformations, does something like them already exist in GHC? Thanks, -- Conal

3 8