- ghc-devs - Haskell.org

RE: Cardinality
by Simon Peyton-Jones 17 Jan '13

17 Jan '13

I don't know how to account for that. Make sure you are compiling everything with -dcore-lint. I guess you are on a Mac? I'm using 64-bit Linux. Is it definitely ok with the old demand analyser? Note for others: this is nofib/imaginary/integrate. Simon From: ilyas239(a)gmail.com [mailto:ilyas239@gmail.com] On Behalf Of Ilya Sergey Sent: 16 January 2013 17:25 To: Simon Peyton-Jones Subject: Re: Cardinality I run nofib and at some point I get the following output: ==nofib== integrate: time to run integrate follows... ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; /bin/sh: line 1: 33635 Bus error: 10 ././integrate +RTS -s/var/folders/c1/pbj77lbx6fnc3qkj984xp44h0000gn/T//stats33626 -RTS +RTS -K20m -H100m -RTS 50000 < /dev/null > /var/folders/c1/pbj77lbx6fnc3qkj984xp44h0000gn/T//runtest33626.1.raw 2> /var/folders/c1/pbj77lbx6fnc3qkj984xp44h0000gn/T//runtest33626.2.raw 3> /var/folders/c1/pbj77lbx6fnc3qkj984xp44h0000gn/T//runtest33626.3.raw real 0m0.922s user 0m0.004s sys 0m0.009s ././integrate +RTS -K20m -H100m -RTS 50000 < /dev/null **** expected exit status 0 not seen ; got 138 /bin/sh: line 1: 33651 Bus error: 10 If I remove integrate from the nofib Makefile, the rest of the benchmarks works just fine. Ilya On Wed, Jan 16, 2013 at 9:19 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: no, I don't. That's odd. How does it manifest for you? S From: ilyas239(a)gmail.com<mailto:ilyas239@gmail.com> [mailto:ilyas239@gmail.com<mailto:ilyas239@gmail.com>] On Behalf Of Ilya Sergey Sent: 16 January 2013 17:13 To: Simon Peyton-Jones Subject: Re: Cardinality Thank you. I ran nofib myself too, and it seems to be fine, except that issue with imaginary/integrate. Did you have that error when running nofib as well? Ilya On Wed, Jan 16, 2013 at 5:39 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: fixed thanks. I'm doing another nofib run now. S From: ilyas239(a)gmail.com<mailto:ilyas239@gmail.com> [mailto:ilyas239@gmail.com<mailto:ilyas239@gmail.com>] On Behalf Of Ilya Sergey Sent: 16 January 2013 12:38 To: Simon Peyton-Jones Subject: Re: Cardinality Hi Simon. I tried to build from the `new-demand-to-merge` branch recently, and I got the following Lint error when building libraries/base/GHC/Event/Array.hs by a stage-1 compiler: *** Core Lint errors : in result of Common sub-expression *** <no location info>: Warning: In a case alternative: (GHC.ForeignPtr.ForeignPtr fo_s3mr :: GHC.Prim.Addr#, ds1_s3mq :: GHC.ForeignPtr.ForeignPtrContents) Occurrence of a dead Id wild_s3ms Any ideas, how it could be fixed, so I could integrate your changes into the cardinality branch and run the experiments? Kind regards, Ilya On Tue, Jan 8, 2013 at 11:22 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: ok. busy working on it now. From: ilyas239(a)gmail.com<mailto:ilyas239@gmail.com> [mailto:ilyas239@gmail.com<mailto:ilyas239@gmail.com>] On Behalf Of Ilya Sergey Sent: 07 January 2013 11:53 To: Simon Peyton-Jones Subject: Re: Cardinality Great, thank you. Please, let me know when it's in the stable state, so I could implement the optimisation making use of single-used thunks (and it would not interfere with your changes). Kind regards, Ilya On Fri, Jan 4, 2013 at 3:11 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: I've been working on the code. Will commit shortly. Integrate seems ok, happily. SImon From: ilyas239(a)gmail.com<mailto:ilyas239@gmail.com> [mailto:ilyas239@gmail.com<mailto:ilyas239@gmail.com>] On Behalf Of Ilya Sergey Sent: 23 December 2012 16:57 To: Simon Peyton-Jones Subject: Re: Cardinality Hi Simon. >From what I can observe, after the trivial merge the new-demand compiled 'integrate' fails (exit code 138), whereas the trunk-compiled one does not. The last time I merged before was November 8, and everything was fine, just as I left it in September. So far, the only difference I can see in the W/W code is that the new-demand compiler makes more aggressive split for the arguments of `integrate1D` (see ww-new.log in the attachment), which seems to be correct to me, as these arguments are used strictly. The compiler from the trunk, however, keeps these arguments boxed, which surprises me (ww-trunk.log). I'm not entirely sure, but it might affect the unpacking strategy on later stages of the simplifier. It would be helpful to know what else I can do to debug this inconsistency. Thanks. Best regards, Ilya On Sun, Dec 23, 2012 at 8:10 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: However, now we have a problem: for one test from nofib, namely imaginary/integrate, the optimizer changes the semantics, so the program fails. Can you be more specific? How does the semantics change? How do you know it is changed? Is this a recent change? Simon From: ilyas239(a)gmail.com<mailto:ilyas239@gmail.com> [mailto:ilyas239@gmail.com<mailto:ilyas239@gmail.com>] On Behalf Of Ilya Sergey Sent: 22 December 2012 19:04 To: Simon Peyton-Jones Subject: Re: Cardinality Dear Simon. Today I spent some time merging 'master' into the 'new-demand-to-merge' branch. It went fine, and I managed to compile it and run the nofib, and results *almost* didn't change: the new strictness analyzer still does better in most of the cases than the old one. However, now we have a problem: for one test from nofib, namely imaginary/integrate, the optimizer changes the semantics, so the program fails. It is quite strange, as from the perspective of the demand analyser the results are similar. As I haven't changed anything in the analysis or the worker/wrapper split, I tend to think it might be the refactoring of the unpacking strategy that clashed with the current logic of W/W. Shall I merge the 'master' into 'new-demand' branch ignoring this issue, or should I keep things as they are, so you could take a look on it and merge it yourself? Kind regards, Ilya On Sat, Dec 22, 2012 at 2:30 AM, Ilya Sergey <ilya.sergey(a)gmail.com<mailto:ilya.sergey@gmail.com>> wrote: Dear Simon. Thank you for the example. I will definitely compile something like this and check the memory consumption. I also have to implement the changes suggested by you and Dimitrios for single-used thunks. The cardinality branch was up-to date with the trunk (and the new demand branch) by mid-November. Yesterday I tried to update it, but by some mysterious reasons I could not compile the current trunk (getting seg-fault). I suspect it might be because of some outdated cabal packages. So once I get the trunk compiled, I will bring both new demand and cardinality branch up to date. I'm still in Saint Petersburg, and will be here until mid-January, waiting for my Spanish visa. Next week I have a deadline for our SCP invited paper, and then for a few weeks I will be focusing exclusively on the cardinality and demand work. Merry Christmas and happy holidays to you and your family! With best regards, Ilya On Fri, Dec 21, 2012 at 9:51 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Ilya I've found an example where cardinality will really help: CPS code. For example, deriving( Read ) generates code (in HEAD, soon) like this expectP x (\v1 -> expectP y (\v2 -> expectP z (\v3 -> ...))) Then the full-laziness (float-out) pass tries to float out lets from those lambdas, because it thinks they may be called many times. But actually they are only called once ... they are continuations ... and the cardinality analysis will discover that I think. I hope to get to this in the new year. What is the state of the cardinality branch? I hope you are enjoying Madrid Simon

1 0

Failing test
by Simon Peyton-Jones 15 Jan '13

15 Jan '13

Iavor Are these four failures the result of your changes? Should we fix the tests? Should the error message say "The instance decl is inconsistent with the fundeps"? And maybe be more precise about which fundep. I'm a bit confused. Simon =====> Gentle(normal) 1182 of 3527 [0, 3, 0] cd ./indexed-types/should_compile && 'C:/code/HEAD/bindisttest/install dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c Gentle.hs >Gentle.comp.stderr 2>&1 Compile failed (status 256) errors were: Gentle.hs:13:10: Illegal instance declaration for `Concrete a b' Multiple uses of this instance may be inconsistent with the functional dependencies of the class. In the instance declaration for `Concrete a b' *** unexpected failure for Gentle(normal) =====> T6068(ghci) 1852 of 3527 [0, 14, 0] cd ./polykinds && HC='C:/code/HEAD/bindisttest/install dir/bin/ghc.exe' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' 'C:/code/HEAD/bindisttest/install dir/bin/ghc.exe' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history <T6068.script >T6068.run.stdout 2>T6068.run.stderr Actual stderr output differs from expected: --- /dev/null 2013-01-14 17:04:32 +0000 +++ ./polykinds/T6068.run.stderr 2013-01-14 17:04:32 +0000 @@ -0,0 +1,9 @@ + +T6068.hs:23:10: + Illegal instance declaration for `HasSingleton + (Maybe ak) (Maybe a) mp' + Multiple uses of this instance may be inconsistent + with the functional dependencies of the class. + In the instance declaration for `HasSingleton (Maybe a) mp' + =====> tc235(normal) 2812 of 3527 [0, 16, 0] cd ./typecheck/should_compile && 'C:/code/HEAD/bindisttest/install dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c tc235.hs -fno-warn-incomplete-patterns >tc235.comp.stderr 2>&1 Compile failed (status 256) errors were: tc235.hs:24:10: Illegal instance declaration for `Gr g ep m' Multiple uses of this instance may be inconsistent with the functional dependencies of the class. In the instance declaration for `Gr g ep m' =====> T5684(normal) 3185 of 3527 [0, 17, 0] cd ./typecheck/should_fail && 'C:/code/HEAD/bindisttest/install dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T5684.hs >T5684.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./typecheck/should_fail/T5684.stderr 2013-01-14 13:42:13 +0000 +++ ./typecheck/should_fail/T5684.comp.stderr 2013-01-14 17:27:00 +0000 @@ -1,64 +1,6 @@ -T5684.hs:25:12: - No instance for (A b6) arising from a use of `op' - In the expression: op True undefined - In the expression: - [op False False, op 'c' undefined, op True undefined] - In an equation for `flop1': - flop1 = [op False False, op 'c' undefined, op True undefined] - -T5684.hs:30:12: - No instance for (A b5) arising from a use of `op' - In the expression: op True undefined - In the expression: - [op False False, op True undefined, op 'c' undefined] - In an equation for `flop2': - flop2 = [op False False, op True undefined, op 'c' undefined] - -T5684.hs:36:12: - No instance for (A b4) arising from a use of `op' - In the expression: op True undefined - In the expression: - [op 'c' undefined, op True undefined, op False False] - In an equation for `flop3': - flop3 = [op 'c' undefined, op True undefined, op False False] - -T5684.hs:42:12: - No instance for (A b3) arising from a use of `op' - In the expression: op True undefined - In the expression: - [op 'c' undefined, op False False, op True undefined] - In an equation for `flop4': - flop4 = [op 'c' undefined, op False False, op True undefined] - -T5684.hs:46:12: - No instance for (A b2) arising from a use of `op' - In the expression: op True undefined - In the expression: - [op True undefined, op 'c' undefined, op False False] - In an equation for `flop5': - flop5 = [op True undefined, op 'c' undefined, op False False] - -T5684.hs:52:12: - No instance for (A b0) arising from a use of `op' - In the expression: op True undefined - In the expression: - [op True undefined, op False False, op 'c' undefined] - In an equation for `flop6': - flop6 = [op True undefined, op False False, op 'c' undefined] - -T5684.hs:53:12: - No instance for (A Bool) arising from a use of `op' - In the expression: op False False - In the expression: - [op True undefined, op False False, op 'c' undefined] - In an equation for `flop6': - flop6 = [op True undefined, op False False, op 'c' undefined] - -T5684.hs:54:12: - No instance for (B Char b1) arising from a use of `op' - In the expression: op 'c' undefined - In the expression: - [op True undefined, op False False, op 'c' undefined] - In an equation for `flop6': - flop6 = [op True undefined, op False False, op 'c' undefined] +T5684.hs:10:10: + Illegal instance declaration for `B Bool b' + Multiple uses of this instance may be inconsistent + with the functional dependencies of the class. + In the instance declaration for `B Bool b' *** unexpected failure for T5684(normal)

2 2

RE: [commit: ghc] master: Use a version of the coverage condition even with UndecidableInstances. (fe61599)
by Simon Peyton-Jones 15 Jan '13

15 Jan '13

OK. I see that * oclose is never used * Note [Important subtlety in oclose] is out of date; it relates to when oclose was used with the global tyvars. This relates to change (1) of yours, behaving uniformly when the fixed tyvars are empty. So I nuked oclose altogether (hurrah), and renamed oclose1 to oclose. I'm happy with (2) using equalities. I'll commit these simplifications shortly. Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Iavor Diatchki | Sent: 14 January 2013 00:30 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Use a version of the coverage condition | even with UndecidableInstances. (fe61599) | | Repository : ssh://darcs.haskell.org//srv/darcs/ghc | | On branch : master | | http://hackage.haskell.org/trac/ghc/changeset/fe61599ffebb27924c4beef47b | 6237542644f3f4 | | >--------------------------------------------------------------- | | commit fe61599ffebb27924c4beef47b6237542644f3f4 | Author: Iavor S. Diatchki <iavor.diatchki(a)gmail.com> | Date: Sun Jan 13 16:29:10 2013 -0800 | | Use a version of the coverage condition even with | UndecidableInstances. | | This fixes bug #1241 and #2247. When UndecidableInstances are on, | we use the "Liberal Coverage Condition", which is what GHC used to | do in | the past. This is the gist of the check: | | class C a b | a -> b | instance theta => C t1 t2 | | we check that `fvs t2` is a subset of `fd-closure(theta,fvs t1)`. | | This is strictly more general than the coverage condition, while | it still guarantees consistency with the FDs of the class. This | check is completely orthogonal to termination (it by no means | guarantees | it). | | I am not sure of the role of the "coverage condition" in | termination--- | the comments suggest that it is important. This is why, for the | moment, | we only use this check when UndecidableInstances are on. | | >--------------------------------------------------------------- | | compiler/typecheck/TcValidity.lhs | 8 ++++- | compiler/types/FunDeps.lhs | 65 | ++++++++++++++++++++++++++++++++++++- | 2 files changed, 71 insertions(+), 2 deletions(-) | | diff --git a/compiler/typecheck/TcValidity.lhs | b/compiler/typecheck/TcValidity.lhs | index 80e7aa0..44d7d4c 100644 | --- a/compiler/typecheck/TcValidity.lhs | +++ b/compiler/typecheck/TcValidity.lhs | @@ -827,7 +827,9 @@ checkValidInstance ctxt hs_type ty | -- in the constraint than in the head | ; undecidable_ok <- xoptM Opt_UndecidableInstances | ; if undecidable_ok | - then checkAmbiguity ctxt ty | + then do checkAmbiguity ctxt ty | + checkTc (checkInstLiberalCoverage clas theta | inst_tys) | + (instTypeErr clas inst_tys liberal_msg) | else do { checkInstTermination inst_tys theta | ; checkTc (checkInstCoverage clas inst_tys) | (instTypeErr clas inst_tys msg) } @@ -837,6 | +839,10 @@ checkValidInstance ctxt hs_type ty | msg = parens (vcat [ptext (sLit "the Coverage Condition fails for | one of the functional dependencies;"), | undecidableMsg]) | | + liberal_msg = vcat | + [ ptext $ sLit "Multiple uses of this instance may be | inconsistent" | + , ptext $ sLit "with the functional dependencies of the class." | + ] | -- The location of the "head" of the instance | head_loc = case hs_type of | L _ (HsForAllTy _ _ _ (L loc _)) -> loc diff --git | a/compiler/types/FunDeps.lhs b/compiler/types/FunDeps.lhs index | 09d0be0..6bca407 100644 | --- a/compiler/types/FunDeps.lhs | +++ b/compiler/types/FunDeps.lhs | @@ -19,7 +19,7 @@ module FunDeps ( | FDEq (..), | Equation(..), pprEquation, | oclose, improveFromInstEnv, improveFromAnother, | - checkInstCoverage, checkFunDeps, | + checkInstCoverage, checkInstLiberalCoverage, checkFunDeps, | pprFundeps | ) where | | @@ -145,6 +145,52 @@ oclose preds fixed_tvs | ClassPred cls tys -> [(cls, tys)] | TuplePred ts -> concatMap classesOfPredTy ts | _ -> [] | + | +-- An alternative implementation of `oclose`. Differences: | +-- 1. The empty set of variables is allowed to determine stuff, | +-- 2. We also use equality predicates as FDs. | +-- | +-- I (Iavor) believe that this is the correct implementation of oclose. | +-- For 1: the above argument about `t` being monomorphic seems | incorrect. | +-- The correct behavior is to quantify over `t`, even though we know | that | +-- it may be instantiated to at most one type. The point is that we | might | +-- only find out what that type is later, at the class site to the | function. | +-- In genral, we should be quantifying all variables that are not | mentioned | +-- in the environment + the variables that are determined by them. | +-- For 2: This is just a nicity, but it makes things a bit more | general: | +-- if we have an assumption `t1 ~ t2`, then we use the fact that if | we know | +-- `t1` we also know `t2` and the other way. | + | +oclose1 :: [PredType] -> TyVarSet -> TyVarSet | +oclose1 preds fixed_tvs | + | null tv_fds = fixed_tvs -- Fast escape hatch for common case. | + | otherwise = loop fixed_tvs | + where | + loop fixed_tvs | + | new_fixed_tvs `subVarSet` fixed_tvs = fixed_tvs | + | otherwise = loop new_fixed_tvs | + where new_fixed_tvs = foldl extend fixed_tvs tv_fds | + | + extend fixed_tvs (ls,rs) | + | ls `subVarSet` fixed_tvs = fixed_tvs `unionVarSet` rs | + | otherwise = fixed_tvs | + | + tv_fds :: [(TyVarSet,TyVarSet)] | + tv_fds = [ (tyVarsOfTypes xs, tyVarsOfTypes ys) | + | (xs, ys) <- concatMap deterimned preds | + ] | + | + deterimned :: PredType -> [([Type],[Type])] | + deterimned pred | + = case classifyPredType pred of | + ClassPred cls tys -> | + do let (cls_tvs, cls_fds) = classTvsFds cls | + fd <- cls_fds | + return (instFD fd cls_tvs tys) | + EqPred t1 t2 -> [([t1],[t2]), ([t2],[t1])] | + TuplePred ts -> concatMap deterimned ts | + _ -> [] | + | \end{code} | | | @@ -471,6 +517,23 @@ checkInstCoverage clas inst_taus | fundep_ok fd = tyVarsOfTypes rs `subVarSet` tyVarsOfTypes ls | where | (ls,rs) = instFD fd tyvars inst_taus | + | +checkInstLiberalCoverage :: Class -> [PredType] -> [Type] -> Bool | +-- Check that the Liberal Coverage Condition is obeyed in an instance | +decl | +-- For example, if we have: | +-- class C a b | a -> b | +-- instance theta => C t1 t2 | +-- Then we require fv(t2) `subset` oclose(fv(t1), theta) | +-- This ensures the self-consistency of the instance, but | +-- it does not guarantee termination. | +-- See Note [Coverage Condition] below | + | +checkInstLiberalCoverage clas theta inst_taus | + = all fundep_ok fds | + where | + (tyvars, fds) = classTvsFds clas | + fundep_ok fd = tyVarsOfTypes rs `subVarSet` oclose1 theta | (tyVarsOfTypes ls) | + where (ls,rs) = instFD fd tyvars inst_taus | \end{code} | | Note [Coverage condition] | | | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

Is there unused code in GHC source?
by Jan Stolarek 15 Jan '13

15 Jan '13

Dear devs, I'm trying to dig into GHC code and one thing is wondering me. Does the source contain old fragments of code that are not used anymore? Well, for such a big project the answer will probably be 'yes', but I'm wondering what the scale of this might be. I thought that such leftovers could be a bit misleading and I want to know if I should stay alert :) Janek

2 2

Understand disassemble for segfault on android
by Nathan Hüsken 13 Jan '13

13 Jan '13

Hey, I am still investigating the segfaults of the exectuable produced by ghc to arm-linux-androideabi cross compiler. I need help. Can someone tell me if my conclusions are correct? The crash happens here: Dump of assembler code for function stg_returnToStackTop: 0x003f059c <+0>: push {r4, lr} 0x003f05a0 <+4>: sub sp, sp, #16 0x003f05a4 <+8>: ldr r1, [r0, #140] ; 0x8c => 0x003f05a8 <+12>: ldr r12, [r1, #12] 0x003f05ac <+16>: ldr r1, [r12, #12] 0x003f05b0 <+20>: mov r2, #0 Since it is in the begining of stg_returnToStackTop, it has to be LOAD_THREAD_STATE(); I believe the code for this is produced by loadThreadState: loadThreadState dflags tso stack = do catAGraphs [ -- tso = CurrentTSO; mkAssign (CmmLocal tso) stgCurrentTSO, -- stack = tso->stackobj; mkAssign (CmmLocal stack) (CmmLoad (cmmOffset dflags (CmmReg (CmmLocal tso)) (tso_stackobj dflags)) (bWord dflags)), (...) So I believe the instruction are mapped like this: ldr r1, [r0, #140] <-> tso = CurrentTSO ldr r12, [r1, #12] <-> stack = tso->stackobj If that is true, the loaded tso pointer ([r0, #140]) must be wrong. When I look at the backtrace at the moment of crash: #0 0x003f0588 in stg_returnToStackTop () #1 0x003c2e74 in schedule (initialCapability=0x3f057c, task=0x52f350) at rts/Schedule.c:463 #2 0x003c2e74 in schedule (initialCapability=0x52f340, task=0x400a42f0) at rts/Schedule.c:463 #3 0x003c4cb0 in scheduleWaitThread (tso=0x401033c0, ret=0x0, pcap=0xbe843b6c) at rts/Schedule.c:2351 There is a "tso" value passed to scheduleWaitThread (tso=0x401033c0). Should be this is the same address, form where the tso is loaded in the instruction: ldr r1, [r0, #140] <-> tso = CurrentTSO ? If so, the value in r0 is way of. info register r0 0x3f057c 4130172 r1 0xe24dd010 -498216944 Are my conclusions so far correct, and I have to find out why r0 is having the wrong value? Thanks! Nathan

1 1

Re: Building on android - compiled program segfaults
by Nathan Hüsken 13 Jan '13

13 Jan '13

Mmh, that does not seem to work. (gdb) strace warning: Couldn't determine the static tracepoint marker to probe Static tracepoint 1 at 0x3f0588 On 01/13/2013 12:56 PM, Conrad Parker wrote: > On 11 January 2013 19:36, Nathan Hüsken <nathan.huesken(a)posteo.de> wrote: >> Hi, >> >> I was succesfull in building ghc (pulled from git) to compile for >> arm-linux-androideabi! >> >> Now using "inplace/bin/ghc-stage1 -dcore-lint -debug" I compiler this >> Main.hs: >> >> main = putStrLn "Hello, World" >> >> I get an executable, which I can run on my android device. Unfortantly >> it segfaults. >> >> Running it with ./Main +RTS -DS gives: >> >> cap 0: initialised >> >> Now I am trying to debug this in gdb. When I try to display the stack >> (which should be in r13 on arm of I understand correctly, I get); >> >> (gdb) p8 $r13 >> 0xbef00a74: 0x0 >> 0xbef00a70: 0x0 >> 0xbef00a6c: 0x3c2e74 >> 0xbef00a68: 0x530350 >> 0xbef00a64: 0x0 >> 0xbef00a60: 0x0 >> 0xbef00a5c: 0x0 >> 0xbef00a58: 0x0 >> >> And now I am clueless. So I tried the good old printf debugging in the >> rts. Using this, I see that it gets before the call to >> scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c). >> >> But when I put a printf in the beginning of scheduleWaitThread (in >> Schedule.c) it is not shown. >> >> What else can I do to find out more? > > can you strace it? > > Conrad. >

1 0

Re: Building on android - compiled program segfaults
by Nathan Hüsken 13 Jan '13

13 Jan '13

There is some more success :). When I do an unregisterised build, it works without segfault. On 01/13/2013 11:16 AM, Bernhard Urban wrote: > Hi Nathan, > > On Fri, Jan 11, 2013 at 12:36 PM, Nathan Hüsken > <nathan.huesken(a)posteo.de> wrote: >> I was succesfull in building ghc (pulled from git) to compile for >> arm-linux-androideabi! > > Great news! > Can you describe how you managed to build it and which environment you use? I am on ubuntu 64 bit. I am planing to share the information in a blog post, but I will wait if I (or someone else) gets the registerised build to work. I made a short writedown of the steps it took here: https://github.com/RudolfVonKrugstein/jshaskell-blog/blob/master/android_gh… Regards, Nathan

1 0

make install failing
by Stephen Paul Weber 13 Jan '13

13 Jan '13

I just did a clean build of my cross-compiling GHC with --prefix set in the top-level ./configure call. When I run `make install` I get: "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg" --force --global-package-db "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/package.conf.d" update rts/package.conf.install /bin/sh: 1: /home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg: not found make[1]: *** [install_packages] Error 127 make: *** [install] Error 2 Grepping the output for pkg: $ make install 2>&1 | grep pkg "rm" -f "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg" ln -s i486-pc-nto-qnx8.0.0-ghc-pkg-7.7.20130112 "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg" "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg" --force --global-package-db "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/package.conf.d" update rts/package.conf.install /bin/sh: 1: /home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg: not found /bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg is a symlink to i486-pc-nto-qnx8.0.0-ghc-pkg-7.7.20130112 which does not exist (and I see no attempt to make it exist), and either way it seems that we are installing with a cross-compile prefix, but not invoking with that. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

1 0

RE: Fundeps and type equality
by Simon Peyton-Jones 12 Jan '13

12 Jan '13

Ian: isn't the documentation URL below supposed to be updated nightly from HEAD? I got it from here: http://www.haskell.org/ghc/download#snapshots S From: ghc-tickets-bounces(a)haskell.org [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of Richard Eisenberg Sent: 11 January 2013 14:42 To: Simon Peyton-Jones Cc: glasgow-haskell-bugs(a)haskell.org; Martin Sulzmann; GHC Users Mailing List Subject: Re: Fundeps and type equality That link looks like it points to the manual for the most recent distribution, not HEAD. The edits I put into the manual for the new family instances are not there, for example. Richard On Jan 11, 2013, at 4:56 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: The manual for HEAD is always online here http://www.haskell.org/ghc/dist/current/docs/html/users_guide/type-families… Simon From: Richard Eisenberg [mailto:eir@cis.upenn.edu] Sent: 11 January 2013 03:03 To: Carter Schonwald Cc: Martin Sulzmann; glasgow-haskell-bugs(a)haskell.org<mailto:glasgow-haskell-bugs@haskell.org>; Simon Peyton-Jones; GHC Users Mailing List Subject: Re: Fundeps and type equality Yes, I finished and pushed in December. A description of the design and how to use the feature is here: http://hackage.haskell.org/trac/ghc/wiki/NewAxioms There's also a section (7.7.2.2 to be exact) in the manual, but building the manual from source is not for the faint of heart. Richard On Jan 10, 2013, at 3:14 PM, Carter Schonwald <carter.schonwald(a)gmail.com<mailto:carter.schonwald@gmail.com>> wrote: so the overlapping type families are in HEAD? Awesome! I look forward to finding some time to try them out :) On Thu, Jan 10, 2013 at 1:56 PM, Richard Eisenberg <eir(a)cis.upenn.edu<mailto:eir@cis.upenn.edu>> wrote: For better or worse, the new overlapping type family instances use a different overlapping mechanism than functional dependencies do. Class instances that overlap are chosen among by order of specificity; overlapping instances can be declared in separate modules. Overlapping family instances must be given an explicit order, and those that overlap must all be in the same module. The decision to make these different was to avoid type soundness issues that would arise with overlapping type family instances declared in separate modules. (Ordering a set of family instance equations by specificity, on the other hand, could easily be done within GHC.) So, as yet, we can't fully encode functional dependencies with type families, I don't think. Richard On Jan 2, 2013, at 4:01 PM, Martin Sulzmann <martin.sulzmann.haskell(a)googlemail.com<mailto:martin.sulzmann.haskell@googlemail.com>> wrote: I agree with Iavor that it is fairly straight-forward to extend FC to support FD-style type improvement. In fact, I've formalized such a proof language in a PPDP'06 paper: "Extracting programs from type class proofs" (type improvement comes only at the end) Similar to FC, coercions (proof terms) are used to represent type equations (improvement). Why extend FC? Why not simply use type families to encode FDs (and thus keep FC simple and small). It's been a while, but as far as I remember, the encoding is only problematic in case of the combination of FDs and overlapping instances. Shouldn't this now be fixable given that type family instances can be overlapping? Maybe I'm missing something, guess it's also time to dig out some old notes ... -Martin On Wed, Jan 2, 2013 at 10:04 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: As far as I understand, the reason that GHC does not construct such proofs is that it can't express them in its internal proof language (System FC). Iavor is quite right It seems to me that it should be fairly straight-forward to extend FC to support this sort of proof, but I have not been able to convince folks that this is the case. I could elaborate, if there's interest. Iavor: I don't think it's straightforward, but I'm willing to be educated. By all means start a wiki page to explain how, if you think it is. I do agree that injective type families would be a good thing, and would deal with the main reason that fundeps are sometimes better than type families. A good start would be to begin a wiki page to flesh out the design issues, perhaps linked fromhttp://hackage.haskell.org/trac/ghc/wiki/TypeFunctions The main issues are, I think: * How to express functional dependencies like "fixing the result type and the first argument will fix the second argument" * How to express that idea in the proof language Simon From: glasgow-haskell-bugs-bounces(a)haskell.org<mailto:glasgow-haskell-bugs-bounces@haskell.org> [mailto:glasgow-haskell-bugs-bounces@haskell.org<mailto:glasgow-haskell-bugs-bounces@haskell.org>] On Behalf Of Iavor Diatchki Sent: 26 December 2012 02:48 To: Conal Elliott Cc: glasgow-haskell-bugs(a)haskell.org<mailto:glasgow-haskell-bugs@haskell.org>; GHC Users Mailing List Subject: Re: Fundeps and type equality Hello Conal, GHC implementation of functional dependencies is incomplete: it will use functional dependencies during type inference (i.e., to determine the values of free type variables), but it will not use them in proofs, which is what is needed in examples like the one you posted. The reason some proving is needed is that the compiler needs to figure out that for each instantiation of the type `ta` and `tb` will be the same (which, of course, follows directly from the FD on the class). As far as I understand, the reason that GHC does not construct such proofs is that it can't express them in its internal proof language (System FC). It seems to me that it should be fairly straight-forward to extend FC to support this sort of proof, but I have not been able to convince folks that this is the case. I could elaborate, if there's interest. In the mean time, the way forward would probably be to express the dependency using type families, which I find tends to be more verbose but, at present, is better supported in GHC. Cheers, -Iavor PS: cc-ing the GHC users' list, as there was some talk of closing the ghc-bugs list, but I am not sure if the transition happened yet. On Tue, Dec 25, 2012 at 6:15 PM, Conal Elliott <conal(a)conal.net<mailto:conal@conal.net>> wrote: I ran into a simple falure with functional dependencies (in GHC 7.4.1): > class Foo a ta | a -> ta > > foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool > foo = (==) I expected that the `a -> ta` functional dependency would suffice to prove that `ta ~ tb`, but Pixie/Bug1.hs:9:7: Could not deduce (ta ~ tb) from the context (Foo a ta, Foo a tb, Eq ta) bound by the type signature for foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool at Pixie/Bug1.hs:9:1-10 `ta' is a rigid type variable bound by the type signature for foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool at Pixie/Bug1.hs:9:1 `tb' is a rigid type variable bound by the type signature for foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool at Pixie/Bug1.hs:9:1 Expected type: ta -> tb -> Bool Actual type: ta -> ta -> Bool In the expression: (==) In an equation for `foo': foo = (==) Failed, modules loaded: none. Any insights about what's going wrong here? -- Conal _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs(a)haskell.org<mailto:Glasgow-haskell-bugs@haskell.org> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org<mailto:Glasgow-haskell-users@haskell.org> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org<mailto:Glasgow-haskell-users@haskell.org> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org<mailto:Glasgow-haskell-users@haskell.org> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 2

Building on android - compiled program segfaults
by Nathan Hüsken 12 Jan '13

12 Jan '13

Hi, I was succesfull in building ghc (pulled from git) to compile for arm-linux-androideabi! Now using "inplace/bin/ghc-stage1 -dcore-lint -debug" I compiler this Main.hs: main = putStrLn "Hello, World" I get an executable, which I can run on my android device. Unfortantly it segfaults. Running it with ./Main +RTS -DS gives: cap 0: initialised Now I am trying to debug this in gdb. When I try to display the stack (which should be in r13 on arm of I understand correctly, I get); (gdb) p8 $r13 0xbef00a74: 0x0 0xbef00a70: 0x0 0xbef00a6c: 0x3c2e74 0xbef00a68: 0x530350 0xbef00a64: 0x0 0xbef00a60: 0x0 0xbef00a5c: 0x0 0xbef00a58: 0x0 And now I am clueless. So I tried the good old printf debugging in the rts. Using this, I see that it gets before the call to scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c). But when I put a printf in the beginning of scheduleWaitThread (in Schedule.c) it is not shown. What else can I do to find out more? Thanks! Nathan

3 7