- Glasgow-haskell-users

Dictionaries and full laziness transformation
by Akio Takano 10 Feb '11

10 Feb '11

Hi, I'm using GHC 7.0.1. I found that recursive overloaded functions tend to leak memory when compiled with full-laziness optimization on. Here is a simple case. -- TestSub.hs {-# LANGUAGE BangPatterns #-} module TestSub where {-# NOINLINE factorial #-} factorial :: (Num a) => a -> a -> a factorial !n !acc = if n == 0 then acc else factorial (n - 1) (acc * n) -- main.hs import TestSub factorial1 :: Int -> Int -> Int factorial1 = factorial main = do n <- readLn print $ factorial1 n 1 main This program should run in constant space, and compiled with -O0 or -O2 -fno-full-laziness, it does. However with -O2, it takes a linear amount of memory. The core for factorial looks like this: TestSub.factorial = \ (@ a_ajm) ($dNum_slz :: GHC.Num.Num a_ajm) -> let { a_slA :: GHC.Classes.Eq a_ajm [LclId] a_slA = GHC.Num.$p1Num @ a_ajm $dNum_slz } in let { lvl2_slC :: a_ajm -> a_ajm -> a_ajm [LclId] lvl2_slC = TestSub.factorial @ a_ajm $dNum_slz } in ... The problem is that lvl2_slC closure is created whenever factorial is applied to a Num dictionary, and kept alive until that application is GCed. In this program it never happens, because an application to the Num Int dictionary is referred to by the factorial1 CAF, and it recursively keeps the whole chain of closures alive. I know that full laziness transformation *sometimes* causes a space leak, but this looks like a bad result to me, because: - It looks like there is no point building a lot of equivalent closures, instead of one. - A lot of code can suffer from this behavior, because overloaded recursive functions are fairly common. For example, unfoldConvStream function from the latest iteratee package suffers from this problem, if I understand correctly. Does anyone have an idea on whether this can be fixed in GHC, or how to work around this problem? Regards, Takano Akio

3 2

my RULES don't fire
by Sebastian Fischer 10 Feb '11

10 Feb '11

Hello, I want to use the RULES pragma and cannot get my rules to fire. Here is a simplified example of what I'm trying. I define my own version of foldMap for lists: fold :: Monoid m => (a -> m) -> [a] -> m fold f = foldr mappend mempty . map f -- alternative, trying to avoid interference with foldr/build fusion -- fold _ [] = mempty -- fold f (x:xs) = f x `mappend` fold f xs {-# NOINLINE fold #-} I try using a NOINLINE pragma to make the firing of my rules (which involve fold) more robust. But they don't fire with or without NOINLINE. Also the uncommented version does not make a difference. I also define a function that creates a singleton list: single :: a -> [a] single x = [x] {-# NOINLINE single #-} Now I want to replace calls of `fold f . g single` (or eta-expanded versions of this) by `g f` using the following rules: {-# RULES "monoid fusion pointfree" forall f (g :: forall m . Monoid m => (a -> m) -> b -> m) . fold f . g single = g f; "monoid fusion pointed, general" forall f (g :: forall m . Monoid m => (a -> m) -> b -> m) b . fold f (g single b) = g f b; "monoid fusion pointed, for lists" forall f (g :: forall m . Monoid m => (a -> m) -> [a] -> m) xs . fold f (g single xs) = g f xs; #-} The variations of type signatures (including no signatures at all) for the pattern variables that I tried did not change anything for the better. I wrote the third rule only because the second gives a warning that I don't quite understand: Warning: Forall'd type variable b is not bound in RULE lhs fold @ m @ a $dMonoid f (g @ [a] $dMonoid (single @ a) b) I try out the rules using the following function that takes the role of `g` in the rules: idGen :: Monoid m => (a -> m) -> [a] -> m idGen _ [] = mempty idGen f (x:xs) = f x `mappend` idGen f xs {-# NOINLINE idGen #-} Again, I use NOINLINE just in case that would help the rules fire. Here is a main function where the rules should fire: main :: IO () main = do print ((fold id . idGen single) [[()]]) print (fold id (idGen single [[()]])) But they don't. Why don't the rules fire, what can I change such that they do, and what to get rid of the warning for the second rule (which I think is the one I should use)? Best regards, Sebastian Here is the output of -ddump-simple-stats (once with -fenable-rewrite-rules only and once with -O): # ghc --version The Glorious Glasgow Haskell Compilation System, version 7.0.1 # ghc -fenable-rewrite-rules -fforce-recomp -ddump-simpl-stats --make rules [1 of 1] Compiling Main ( rules.hs, rules.o ) ==================== Grand total simplifier statistics ==================== Total ticks: 0 1 SimplifierDone 1 # ghc -O -fforce-recomp -ddump-simpl-stats --make rules [1 of 1] Compiling Main ( rules.hs, rules.o ) ==================== FloatOut stats: ==================== 0 Lets floated to top level; 0 Lets floated elsewhere; from 4 Lambda groups ==================== FloatOut stats: ==================== 10 Lets floated to top level; 1 Lets floated elsewhere; from 5 Lambda groups ==================== Grand total simplifier statistics ==================== Total ticks: 144 34 PreInlineUnconditionally 1 eta_Xp5 1 g_amr 1 eta_amx 1 k_amJ 1 z_amK 1 f_amQ 1 g_amR 1 x_amS 1 k_an9 1 z_ana 1 g_anb 1 f_anf 1 xs_ang 1 eta_aoA 2 $dShow_aKW 2 x_aKX 1 ys_aVd 1 c_dmm 1 n_dmn 1 a_snX 1 a_so1 1 lvl_sod 1 lvl_soe 1 lvl_sof 1 lvl_sog 1 lvl_soh 1 lvl_soi 1 lvl_soj 1 a_son 1 a_sop 1 a_sV0 1 a_sV2 17 PostInlineUnconditionally 1 k_amv 1 f_amQ 1 g_amR 1 c_ani 1 n_anj 1 m_anI 1 k_anJ 2 $dShow_aoy 2 x_aoz 1 c_aVa 1 f_aVb 1 x_aVc 1 a_snV 1 a_snZ 1 lvl_sVA 15 UnfoldingDone 1 GHC.Base.build 1 GHC.Base.foldr 2 System.IO.print 1 GHC.TopHandler.runMainIO 2 GHC.Base.. 1 GHC.Base.mapFB 1 GHC.Base.$fMonadIO_$c>> 2 Main.main 2 System.IO.print1 2 GHC.Show.$fShow[]_$cshow 8 RuleFired 1 Class op >> 2 Class op show 2 Class op showList 1 fold/build 1 foldr/nil 1 map 8 LetFloatFromLet 8 62 BetaReduction 1 eta_Xp5 1 a_amq 1 g_amr 1 a_amt 1 b_amu 1 k_amv 1 z_amw 1 eta_amx 1 b_amH 1 a_amI 1 k_amJ 1 z_amK 2 b_amN 2 c_amO 2 a_amP 2 f_amQ 2 g_amR 1 x_amS 1 a_an7 1 b_an8 1 k_an9 1 z_ana 1 g_anb 1 a_and 1 a1_ane 1 f_anf 1 xs_ang 1 b_anh 1 c_ani 1 n_anj 1 a_anG 1 b_anH 1 m_anI 1 k_anJ 2 a_aox 2 $dShow_aoy 2 x_aoz 1 eta_aoA 2 a_aKV 2 $dShow_aKW 2 x_aKX 1 elt_aV7 1 lst_aV8 1 a_aV9 1 c_aVa 1 f_aVb 1 x_aVc 1 ys_aVd 1 a_dml 1 c_dmm 1 n_dmn 13 SimplifierDone 13

2 3

RFC: migrating to git
by Simon Marlow 10 Feb '11

10 Feb '11

It's time to consider again whether we should migrate GHC development from darcs to (probably) git. From our perspective at GHC HQ, the biggest problem that we would hope to solve by switching is that darcs makes branching and merging very difficult for us. We have a few branches of HEAD that are very painful to keep merged with HEAD, and we would almost certainly have more branches if the overhead were lower. In some sense the overhead is self-inflicted because we have the no-conflict policy in the mainline repository, but that is to avoid problems with darcs' merging algorithms (both performance and correctness). We are still using darcs v1 patches rather than v2, but there are known problems with v2 which are preventing us from upgrading. The darcs team have been making great strides with performance, but conflict handling remains a serious problem. The darcs roadmap doesn't show this being fixed in the near future http://wiki.darcs.net/Roadmap Rebase support is coming, and it does work, though the workflow is a bit laborious. Besides the branching/merging/conflict issue, switching to git would give us plenty of side benefits, notably via access to a wealth of tool support. Making contribution easy is important to us too, and there are a lot of people using git. The cost of switching is quite high, which is one reason we decided to stay with darcs last time. We have multiple repos that need to be converted, and for some of them, where the repo is being shared with other projects, we may have to mirror rather than convert in place. We're prepared to put in the effort if the gains would be worthwhile though (offers of help are more than welcome!). We're intrested in opinions from both active and potential GHC developers/contributors. Let us know what you think - would this make life harder or easier for you? Would it make you less likely or more likely to contribute? Cheers, Simon

34 81

Re: System.Posix.Signals weirdness
by Simon Marlow 08 Feb '11

08 Feb '11

> I'd expect the following program (compiled with ghc and without any > specieal flags) to produce > > Just (Exited ExitSuccess) > True > > but it produces > > Just (Exited ExitSuccess) > False > > on Debian Lenny (ghc-6.8), OpenBSD-current (ghc-6.12.3), OpenBSD-current > (ghc=7.0 from the 7.0 branch). > > module Main where > > import Data.IORef > import System.Posix.Process > import System.Posix.Signals > import System.Posix.Unistd > > main = do > caughtCHLD <- newIORef False > installHandler sigCHLD (Catch $ writeIORef caughtCHLD True) Nothing > pid <- forkProcess $ sleep 2 >> return () > s <- sleep 8 > getProcessStatus False False pid >>= print > readIORef caughtCHLD >>= print > > The sigCHLD handler is never called in this program. Is this expected > behaviour? If so, why? If you change the "sleep" to "threadDelay", you get the expected answer. The reason is that sleep is a foreign call, and in the unthreaded RTS no other threads can run while the foreign call is in progress, and that includes threads created to handle signals. When sleep returns, there isn't enough time before the main thread exits for the sigCHLD handler thread to run. threadDelay is more friendly and lets the RTS run other threads. You could also use -threaded, but then the sleep call will be interrupted by SIGVTALRM, so using threadDelay is better. Cheers, Simon

1 0

Alex Mason wants to stay in touch on LinkedIn
by Alex Mason 07 Feb '11

07 Feb '11

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Alex Mason Alex Mason Computer Science Tutor at Australian National University Canberra Area, Australia Confirm that you know Alex Mason https://www.linkedin.com/e/3s7ug4-gjv7nt1u-3a/isd/2281459363/cVZraxml/ -- (c) 2011, LinkedIn Corporation

2 1

a compiled program is slower than byte code
by Kazu Yamamoto 07 Feb '11

07 Feb '11

Hello, If I compile the attach code with GHC of the newest ghc-7.0 darcs branch, the compiled program is much slower than byte code. This phenomenon does not exist in GHC 6.12.3. 6.12.3 runghc -- 6.23s user 0.59s system 98% cpu 6.912 total ghc -- 5.72s user 0.70s system 99% cpu 6.422 total ghc -O -- 5.70s user 0.67s system 99% cpu 6.376 total ghc -O2 -- 5.69s user 0.67s system 99% cpu 6.373 total ghc-7.0 runghc -- 6.43s user 0.10s system 99% cpu 6.593 total ghc -- 9.20s user 0.09s system 99% cpu 9.302 total ghc -O -- 9.20s user 0.09s system 99% cpu 9.298 total ghc -O2 -- 9.38s user 0.09s system 99% cpu 9.478 total Is this a bug? My environment is Mac which runs Snow Leopard. --Kazu ---- import System.IO n :: Int n = 10000 main :: IO () main = withFile "/dev/null" WriteMode $ \h -> hPutStr h . foldr1 (++) . replicate n . replicate n $ 'a' ----

1 0

System.Posix.Signals weirdness
by Matthias Kilian 07 Feb '11

07 Feb '11

Hi, I'd expect the following program (compiled with ghc and without any specieal flags) to produce Just (Exited ExitSuccess) True but it produces Just (Exited ExitSuccess) False on Debian Lenny (ghc-6.8), OpenBSD-current (ghc-6.12.3), OpenBSD-current (ghc=7.0 from the 7.0 branch). module Main where import Data.IORef import System.Posix.Process import System.Posix.Signals import System.Posix.Unistd main = do caughtCHLD <- newIORef False installHandler sigCHLD (Catch $ writeIORef caughtCHLD True) Nothing pid <- forkProcess $ sleep 2 >> return () s <- sleep 8 getProcessStatus False False pid >>= print readIORef caughtCHLD >>= print The sigCHLD handler is never called in this program. Is this expected behaviour? If so, why? Ciao, Kili

1 0

OSX i386/x86 and x86_64 - time to switch supported platforms?
by Max Cantor 05 Feb '11

05 Feb '11

The last 32-bit, Intel Mac was the Mac Mini, discontinued in August 2007. The bulk of them were discontinued in 2006, along with PowerPC Macs. Does it make sense to relegate OSX x86_64 to community status while the 32-bit version is considered a supported platform? Given that I'm far from experienced enough to be able to contribute meaningfully to GHC, I'm not complaining about anyone's efforts, just that those efforts might be a bit misallocated. I'd venture a guess that far more people are interested in running 64-bit GHC on OSX than in running GHC on what is now fairly antiquated hardware. mc

6 7

4221 on new codegen
by Edward Z. Yang 04 Feb '11

04 Feb '11

Test 4221 (under the ffi folder) segfaults with the new codegen turned on. Before: 0xb7a68c78: 0x822fadc <stg_ap_v_info> 0xb7a68c74: 0xb7ab8f94 0xb7a68c70: 0xb7ab8fa4 0xb7a68c6c: 0x8134dc0 <stT_info> 0xb7a68c68: 0xb7ab8f94 0xb7a68c64: 0x822f9f4 <stg_marked_upd_frame_info> 0xb7a68c60: 0xb7ab8f48 0xb7a68c5c: 0xb7ab8f88 0xb7a68c58: 0x4063a000 # this is the counted float; this 0xb7a68c54: 0x0 # val is 157.0 0xb7a68c50: 0x804bbc0 <c1jG_info> After: 0xb7a68c78: 0x822fadc <stg_ap_v_info> 0xb7a68c74: 0xb7ab8f94 0xb7a68c70: 0xb7ab8fa4 0xb7a68c6c: 0x8134dc0 <stT_info> 0xb7a68c68: 0xb7ab8f94 0xb7a68c64: 0x822f9f4 <stg_marked_upd_frame_info> 0xb7a68c60: 0xb7ab8f48 0xb7a68c5c: 0xb7ab8f88 0xb7a68c58: 0x4063a000 0xb7a68c54: 0x0 It then jumps c1jL_entry to which jumps to stg_gc_d1_info which segfaults on return because 0xb7a68c54 is not a valid address. The offending assembly: (gdb) disas Dump of assembler code for function c1jG_info: 0x0804bbc0 <+0>: fldl 0x4(%ebp) 0x0804bbc3 <+3>: fstp %st(1) 0x0804bbc5 <+5>: fstl 0x4(%ebp) 0x0804bbc8 <+8>: add $0x4,%ebp => 0x0804bbcb <+11>: ffree %st(0) 0x0804bbcd <+13>: ffree %st(1) 0x0804bbcf <+15>: ffree %st(2) 0x0804bbd1 <+17>: ffree %st(3) 0x0804bbd3 <+19>: ffree %st(4) 0x0804bbd5 <+21>: ffree %st(5) 0x0804bbd7 <+23>: jmp 0x804bbdc <c1jL_entry> 0x0804bbd9 <+25>: lea 0x0(%esi),%esi Optimized C--: block_c1jG_entry() { [const 484;, const 32;] } c1jG: // emitReturn: Sequel: Assign _s1ev::F64 = F64[Sp + 4]; ; F64[Sp + 4] = _s1ev::F64; Sp = Sp + 4; jump block_c1jL_entry (); } Regardless of whether or not it's right, this is pretty dumb code, so we should fix the codegen not to do that. I'm not sure what this code is /supposed/ to be doing, or what generated it. This bit might be correct and the FFI call leading up to it may be wrong. I have a prodigous amout of difficulty trying to figure out if what's on the stack is right or not: maybe we could have a chat about this. Cheers, Edward Some possible useful raw data: Raw C--: block_c1jh_entry() { [const 484;, const 32;] } c1jh: // emitReturn: Sequel: Assign _s1ev::F64 = F64[Sp + 4]; _s1ev::F64 = _s1ev::F64; F64[Sp + 4] = _s1ev::F64; Sp = Sp + 4; jump block_c1jm_entry (); } after manifest SP {offset c1j0: _s1el::I32 = I32[Sp + 4]; // CmmAssign I32[Sp - 4] = _s1el::I32; // CmmStore _s1ei::I32 = I32[Sp + 0]; // CmmAssign if (Sp - 12 < SpLim) goto u1Am; else goto u1Ao; // CmmCondBranch u1Am: Sp = Sp + 12; // CmmAssign goto c1j7; // CmmBranch c1j7: // outOfLine here R1 = call_fn_blob_rk2_closure; // CmmAssign Sp = Sp - 12; // CmmAssign call (stg_gc_fun)(...) returns to Nothing (12) (0) with update frame 12; // CmmCall u1Ao: Sp = Sp + 12; // CmmAssign goto c1j3; // CmmBranch c1j3: // outOfLine should follow: if (_s1ei::I32 & 3 != 0) goto c1j9; else goto c1j8; // CmmCondBranch c1j9: // emitReturn: Sequel: Assign _s1fO::I32 = _s1ei::I32; // CmmAssign I32[Sp - 20] = _s1fO::I32; // CmmStore goto u1Ai; // CmmBranch u1Ai: Sp = Sp - 20; // CmmAssign goto c1jc; // CmmBranch c1j8: // emitCall: Sequel: Assign R1 = _s1ei::I32; // CmmAssign I32[Sp - 20] = c1iw; // CmmStore Sp = Sp - 20; // CmmAssign call (I32[_s1ei::I32])(...) returns to Just c1iw (4) (4) with update frame 4; // CmmCall c1iw: _s1fO::I32 = R1; // CmmAssign I32[Sp + 0] = _s1fO::I32; // CmmStore Sp = Sp + 4; // CmmAssign goto u1Af; // CmmBranch u1Af: Sp = Sp - 4; // CmmAssign goto c1jc; // CmmBranch c1jc: // outOfLine should follow: _s1fO::I32 = I32[Sp + 0]; // CmmAssign _s1ep::I32 = I32[_s1fO::I32 + 3]; // CmmAssign I32[Sp + 0] = _s1ep::I32; // CmmStore _s1el::I32 = I32[Sp + 4]; // CmmAssign if (_s1el::I32 & 3 != 0) goto c1jf; else goto c1je; // CmmCondBranch c1jf: // emitReturn: Sequel: Assign _s1el::I32 = I32[Sp + 4]; // CmmAssign _s1fP::I32 = _s1el::I32; // CmmAssign I32[Sp - 4] = _s1fP::I32; // CmmStore goto u1Aj; // CmmBranch u1Aj: Sp = Sp - 4; // CmmAssign goto c1jj; // CmmBranch c1je: // emitCall: Sequel: Assign _s1el::I32 = I32[Sp + 4]; // CmmAssign R1 = _s1el::I32; // CmmAssign I32[Sp - 4] = c1iG; // CmmStore _s1el::I32 = I32[Sp + 4]; // CmmAssign Sp = Sp - 4; // CmmAssign call (I32[_s1el::I32])(...) returns to Just c1iG (4) (4) with update frame 4; // CmmCall c1iG: _s1fP::I32 = R1; // CmmAssign I32[Sp + 0] = _s1fP::I32; // CmmStore Sp = Sp + 4; // CmmAssign goto u1Ag; // CmmBranch u1Ag: Sp = Sp - 4; // CmmAssign goto c1jj; // CmmBranch c1jj: // outOfLine should follow: _s1fP::I32 = I32[Sp + 0]; // CmmAssign _s1eq::F64 = F64[_s1fP::I32 + 3]; // CmmAssign I32[Sp + 0] = c1jh; // CmmStore _s1ep::I32 = I32[Sp + 4]; // CmmAssign foreign call "ccall" arg hints: [PtrHint,] result hints: [] call_fn_blob(...) returns to c1jh args: ([_s1ep::I32, _s1eq::F64]) ress: ([_s1ev::F64]) with update frame 4; // CmmForeignCall c1jh: // emitReturn: Sequel: Assign _s1ev::F64 = F64[Sp + 4]; // CmmAssign _s1ev::F64 = _s1ev::F64; // CmmAssign F64[Sp + 4] = _s1ev::F64; // CmmStore Sp = Sp + 4; // CmmAssign goto u1Ak; // CmmBranch u1Ak: goto c1jm; // CmmBranch c1jm: Hp = Hp + 12; // CmmAssign if (Hp > HpLim) goto c1jn; else goto c1jl; // CmmCondBranch c1jn: HpAlloc = 12; // CmmAssign // outOfLine here _s1ev::F64 = F64[Sp + 0]; // CmmAssign F64[Sp - 4] = _s1ev::F64; // CmmStore I32[Sp + 4] = c1iT; // CmmStore Sp = Sp - 4; // CmmAssign call stg_gc_d1(...) returns to Just c1iT (12) (12) with update frame 4; // CmmCall c1iT: _s1ev::F64 = F64[Sp + 0]; // CmmAssign F64[Sp + 4] = _s1ev::F64; // CmmStore Sp = Sp + 12; // CmmAssign goto u1Ah; // CmmBranch u1Ah: Sp = Sp - 8; // CmmAssign goto c1jm; // CmmBranch c1jl: // outOfLine should follow: // allocDynClosure I32[Hp - 8] = GHC.Types.D#_con_info; // CmmStore _s1ev::F64 = F64[Sp + 0]; // CmmAssign F64[Hp - 4] = _s1ev::F64; // CmmStore _c1iZ::I32 = Hp - 8; // CmmAssign // emitReturn: Sequel: Return R1 = _c1iZ::I32 + 1; // CmmAssign Sp = Sp + 16; // CmmAssign call (I32[Sp + 0])(...) returns to Nothing (4) (0) with update frame 4; // CmmCall } post dead assignment elimination {offset c1j0: _s1el::I32 = I32[(old + 8)]; // CmmAssign I32[(slot<_s1el::I32> + 4)] = _s1el::I32; // CmmStore _s1ei::I32 = I32[(old + 12)]; // CmmAssign if (Sp - <highSp> < SpLim) goto c1j7; else goto c1j3; // CmmCondBranch c1j7: // outOfLine here R1 = call_fn_blob_rk2_closure; // CmmAssign call (stg_gc_fun)(...) returns to Nothing (12) (0) with update frame 12; // CmmCall c1j3: // outOfLine should follow: if (_s1ei::I32 & 3 != 0) goto c1j9; else goto c1j8; // CmmCondBranch c1j9: // emitReturn: Sequel: Assign _s1fO::I32 = _s1ei::I32; // CmmAssign I32[(slot<_s1fO::I32> + 4)] = _s1fO::I32; // CmmStore goto u1Ai; // CmmBranch u1Ai: goto c1jc; // CmmBranch c1j8: // emitCall: Sequel: Assign R1 = _s1ei::I32; // CmmAssign I32[(young<c1iw> + 4)] = c1iw; // CmmStore call (I32[_s1ei::I32])(...) returns to Just c1iw (4) (4) with update frame 4; // CmmCall c1iw: _s1fO::I32 = R1; // CmmAssign I32[(slot<_s1fO::I32> + 4)] = _s1fO::I32; // CmmStore goto u1Af; // CmmBranch u1Af: goto c1jc; // CmmBranch c1jc: // outOfLine should follow: _s1fO::I32 = I32[(slot<_s1fO::I32> + 4)]; // CmmAssign _s1ep::I32 = I32[_s1fO::I32 + 3]; // CmmAssign I32[(slot<_s1ep::I32> + 4)] = _s1ep::I32; // CmmStore _s1el::I32 = I32[(slot<_s1el::I32> + 4)]; // CmmAssign if (_s1el::I32 & 3 != 0) goto c1jf; else goto c1je; // CmmCondBranch c1jf: // emitReturn: Sequel: Assign _s1el::I32 = I32[(slot<_s1el::I32> + 4)]; // CmmAssign _s1fP::I32 = _s1el::I32; // CmmAssign I32[(slot<_s1fP::I32> + 4)] = _s1fP::I32; // CmmStore goto u1Aj; // CmmBranch u1Aj: goto c1jj; // CmmBranch c1je: // emitCall: Sequel: Assign _s1el::I32 = I32[(slot<_s1el::I32> + 4)]; // CmmAssign R1 = _s1el::I32; // CmmAssign I32[(young<c1iG> + 4)] = c1iG; // CmmStore _s1el::I32 = I32[(slot<_s1el::I32> + 4)]; // CmmAssign call (I32[_s1el::I32])(...) returns to Just c1iG (4) (4) with update frame 4; // CmmCall c1iG: _s1fP::I32 = R1; // CmmAssign I32[(slot<_s1fP::I32> + 4)] = _s1fP::I32; // CmmStore goto u1Ag; // CmmBranch u1Ag: goto c1jj; // CmmBranch c1jj: // outOfLine should follow: _s1fP::I32 = I32[(slot<_s1fP::I32> + 4)]; // CmmAssign _s1eq::F64 = F64[_s1fP::I32 + 3]; // CmmAssign I32[(young<c1jh> + 4)] = c1jh; // CmmStore _s1ep::I32 = I32[(slot<_s1ep::I32> + 4)]; // CmmAssign foreign call "ccall" arg hints: [PtrHint,] result hints: [] call_fn_blob(...) returns to c1jh args: ([_s1ep::I32, _s1eq::F64]) ress: ([_s1ev::F64]) with update frame 4; // CmmForeignCall c1jh: // emitReturn: Sequel: Assign _s1ev::F64 = F64[(slot<_s1ev::F64> + 8)]; // CmmAssign _s1ev::F64 = _s1ev::F64; // CmmAssign F64[(slot<_s1ev::F64> + 8)] = _s1ev::F64; // CmmStore goto u1Ak; // CmmBranch u1Ak: goto c1jm; // CmmBranch c1jm: Hp = Hp + 12; // CmmAssign if (Hp > HpLim) goto c1jn; else goto c1jl; // CmmCondBranch c1jn: HpAlloc = 12; // CmmAssign // outOfLine here _s1ev::F64 = F64[(slot<_s1ev::F64> + 8)]; // CmmAssign F64[(young<c1iT> + 12)] = _s1ev::F64; // CmmStore I32[(young<c1iT> + 4)] = c1iT; // CmmStore call stg_gc_d1(...) returns to Just c1iT (12) (12) with update frame 4; // CmmCall c1iT: _s1ev::F64 = F64[(young<c1iT> + 12)]; // CmmAssign F64[(slot<_s1ev::F64> + 8)] = _s1ev::F64; // CmmStore goto u1Ah; // CmmBranch u1Ah: goto c1jm; // CmmBranch c1jl: // outOfLine should follow: // allocDynClosure I32[Hp - 8] = GHC.Types.D#_con_info; // CmmStore _s1ev::F64 = F64[(slot<_s1ev::F64> + 8)]; // CmmAssign F64[Hp - 4] = _s1ev::F64; // CmmStore _c1iZ::I32 = Hp - 8; // CmmAssign // emitReturn: Sequel: Return R1 = _c1iZ::I32 + 1; // CmmAssign call (I32[(old + 4)])(...) returns to Nothing (4) (0) with update frame 4; // CmmCall }

4 13

Re: [Haskell-cafe] How to #include into .lhs files?
by Max Bolingbroke 04 Feb '11

04 Feb '11

On 4 February 2011 05:03, Michael Snoyman <michael(a)snoyman.com> wrote: > My guess (a complete guess) is that the deliterate step is creating a > temporary .hs file elsewhere on your filesystem, which is why the CPP > step can't find B.hs without a fully-qualified path. That is what is happening (you can confirm with "ghc -v"). Interestingly, you can work around by compiling with -I. on the command line: {{{ mbolingbroke@equinox ~/Junk/lhscpp $ cat Test.lhs Included.h > {-# LANGUAGE CPP #-} > module Main (main) where #include "MachDeps.h" #include "Included.h" > main :: IO () > main = print MY_CONSTANT #define MY_CONSTANT 2 mbolingbroke@equinox ~/Junk/lhscpp $ ./Test 2 }}} Perhaps worth filing a bug report? Cheers Max

1 0