- Glasgow-haskell-users

Recompile with -fPIC (was "building a patched ghc")
by José Pedro Magalhães 20 Feb '11

20 Feb '11

Hi all, I'm getting the same error as Alexy below in some 64bit linux system. What can I do? Adding -fPIC and also -dynamic does not seem to solve the problem. Also, this only happens with a perf build; devel1 works fine. Thanks, Pedro On Sat, Jun 26, 2010 at 05:56, braver <deliverable(a)gmail.com> wrote: > An attempt to build the trunk gets me this: > > /opt/portage/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64- > pc-linux-gnu/bin/ld: rts/dist/build/RtsStartup.dyn_o: relocation > R_X86_64_PC32 against symbol `StgRun' can not be used when making a > shared object; recompile with -fPIC > > -- I use prefix portage on a CentOS box, admittedly a non-standard > setup. Its gcc is found first and it wants -fPIC... Should I just > add it to CFLAGS or what? > > -- Alexy > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

3 3

Behavior of the -H RTS option, possible doc/impl mismatch
by Akio Takano 18 Feb '11

18 Feb '11

Hi, I have questions regarding to the -H RTS option. I use GHC 7.0.1 on Linux x86-64. The User's Guide says: -Hsize [Default: 0] This option provides a “suggested heap size” for the garbage collector. The garbage collector will use about this much memory until the program residency grows and the heap size needs to be expanded to retain reasonable performance. However the actual behavior seems to be quite different. As an example, for a particular program: ./a.out +RTS -N7 -A256M -H2G uses around 7 GBytes of memory ./a.out +RTS -N7 -A256M -H6G uses around 13 GBytes of memory If the User's Guide is correct, changing -H2G to -H6G should not increase the heap usage beyond 6 GBytes. In the rts source, I see the parameter value (RtsFlags.GcFlags.heapSizeSuggestion) is used only to adjust the size of the allocation areas, not the entire heap. How is the -H option supposed to behave? How does it behave currently? Regards, Takano Akio

3 3

Re: [Haskell-cafe] Using MonadFix to tie the knot with STM
by Antoine Latter 17 Feb '11

17 Feb '11

On Sat, Feb 12, 2011 at 8:47 AM, Sebastiaan Visser <haskell(a)fvisser.nl> wrote: > Hi all, > > During a little experiment I discovered there is no MonadFix instance available for the STM monad. Is this absence the consequence of some deep restriction of how STM works or 'just accidental'? Is there some way I could derive this instance? If you port `fixST` to the STM monad, it seems to work fine at first glance: http://hpaste.org/43915/fixstm But I would want someone else's opinion on it to make sure I'm not doing something like introducing lazy STM values that violate atomicity, or something. The strict `case` on the return value makes me feel pretty good about it. Antoine > > For those who are interested and may know other ways to solve my problem, I'm trying to tie the knot in a graph by using transactional variables as the edges between nodes. I'm trying to do this in a rather generic way: > >> {-# LANGUAGE DeriveFunctor, DeriveFoldable, DeriveTraversable, StandaloneDeriving, DoRec #-} >> module Graph where >> >> import Control.Applicative >> import Control.Concurrent.STM >> import Control.Monad.Fix >> import Data.Maybe >> import Data.Foldable >> import Data.Traversable >> import Prelude hiding (mapM) >> import qualified Data.Map as M >> >> instance MonadFix STM where >> mfix = error "I need this instance!" -- What to do? >> >> -- A single node is a graph, has a list of both incoming and outgoing edges. >> >> data Node edge = Node >> { nodeId :: NodeId >> , payload :: String >> , incoming :: [edge] >> , ougoing :: [edge] >> } deriving (Functor, Foldable, Traversable) >> >> type NodeId = String >> >> -- A graph with an index on the nodes by NodeId, parametrized with the type we >> -- want to used as the edge pointer. >> >> type Graph edge = M.Map NodeId (Node edge) >> >> -- Type level fixed point combinator with a TVar annotation. >> >> newtype TFix f = TIn { tout :: TVar (f (TFix f)) } >> >> -- Take a graph that uses NodeIds as edges and recursively transform it into a >> -- graph with TVars to the neighbouring nodes in the edges. >> >> tieTheKnot :: Graph NodeId -> STM (Graph (TFix Node)) >> tieTheKnot untied = >> do rec tied <- (mapM . mapM) (\nodeid -> TIn <$> newTVar (tryLookup nodeid tied)) untied >> return tied >> >> -- Helper function to lookup a pre-tied node from a graph, throws an error when >> -- the edge could not be resolved. This should, of course, not happen! >> >> tryLookup :: NodeId -> Graph (TFix Node) -> Node (TFix Node) >> tryLookup i = fromJust (error msg) . M.lookup i >> where msg = "tieTheKnot: Lookup error, input is an incomplete graph." > > Thanks in advance, > > -- > Sebastiaan Visser > http://www.silkapp.com > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

3 2

Injective type families?
by Conal Elliott 16 Feb '11

16 Feb '11

Is there a way to declare a type family to be injective? I have > data Z > data S n > type family n :+: m > type instance Z :+: m = m > type instance S n :+: m = S (n :+: m) My intent is that (:+:) really is injective in each argument (holding the other as fixed), but I don't know how to persuade GHC, leading to some compilation errors like the following: Couldn't match expected type `m :+: n' against inferred type `m :+: n1' NB: `:+:' is a type function, and may not be injective I realize that someone could add more type instances for (:+:), breaking injectivity. Come to think of it, I don't know how GHC could even figure out that the two instances above do not overlap on the right-hand sides. Since this example is fairly common, I wonder: does anyone have a trick for avoiding the injectivity issue? Thanks, - Conal

8 9

Re: a compiled program is slower than byte code
by Simon Marlow 15 Feb '11

15 Feb '11

> 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? I don't see the same results here (x86_64/Linux). This is the 7.0 branch built last night: $ ghc-stable-nightly2 ./kazu.hs -O2 -fforce-recomp; time ./kazu [1 of 1] Compiling Main ( kazu.hs, kazu.o ) Linking kazu ... 8.58s real 8.54s user 0.04s system 99% ./kazu $ time runghc -f ghc-stable-nightly2 ./kazu.hs -O2 -fforce-recomp; 16.92s real 14.21s user 2.70s system 99% runghc -f ghc-stable-nightly2 ./kazu.hs -O2 -fforce-recomp However, there is a fairly large difference between the 7.0 branch and HEAD: $ ghc-nightly2 ./kazu.hs -O2 -fforce-recomp; time ./kazu [1 of 1] Compiling Main ( kazu.hs, kazu.o ) Linking kazu ... 4.17s real 4.16s user 0.01s system 99% ./kazu HEAD is more than twice as fast on this program. Fusion not working, perhaps? Cheers, Simon > 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' > ----

2 4

Trying to build Agda 2.2.9 with ghc-7.1.20110131
by Pavel Perikov 14 Feb '11

14 Feb '11

If anyone interested... Agda-2.2.9 compiled perfectly with 7.0.1 release but with 7.1.20110131 the compiler had a few problems including "impossible happened" when building profiling library. Another one was in src/full/Agda/TypeChecking/Positivity.hs @ 260: instance ComputeOccurrences Term where occurrences vars v = case v of Var i args -> maybe Map.empty here (vars ! fromIntegral i) .......................... where vs ! i | i < length vs = vs !! i | otherwise = error $ show vs ++ " ! " ++ show i ++ " (" ++ show v ++ ")" Compiler complained about ! in "vars ! fromIntegral" suggesting Map.! after i changed the code to where (!) vs i | i < length vs = vs !! i | otherwise = error $ show vs ++ " ! " ++ show i ++ " (" ++ show v ++ ")" everything proceeded as expected. I also had to give -XFlexibleInstances and -XBangPatterns that was not required previously. Agda can be got from darcs get http://code.haskell.org/Agda/ pavel.

3 2

Adventures with threadDelay Mac OS X
by Pavel Perikov 13 Feb '11

13 Feb '11

hi list. I tried to build myself 64-bit compiler under mac os x. I started with the distribution of 7.0.1 provided by Gregory Wright. It installed and worked fine but 7.0.1 has some known bugs so I moved on to later snapshots. Unfortunately all the versions I tried had weird threadDelay behavior (64-bit, Mac OS X) 7.1.20110131 DEVELOPMENT - threadDelay returns immediately STABLE branch 7.0.1.20110201, 7.0.1.20110211 - threadDelay hangs forever I tried searching trac quickly but did not found anything relevant. Is this a known problem? just to add some fun - i noticed the problem because when working in agda Auto prover hanged instead of answering "No solution found (5s)" :) pavel

2 2

StgExpr AST
by Chris Nicholls 10 Feb '11

10 Feb '11

Hello, Is there a way to get access to the STG syntax tree of a program using the GHC api? i.e. a function that returns something of type `StgExpr' that can be used in a way similar to this: example module = defaultErrorHandler defaultDynFlags $ do runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags dflags target <- guessTarget targetFile Nothing setTargets [target] load LoadAllTargets modSum <- getModSummary $ mkModuleName module p <- parseModule modSum t <- typecheckModule p d <- desugarModule t c <- return $ coreModule d s <- coreToStg c return s Thanks for any help, Chris

2 1

Deriviable type classes
by Simon Peyton-Jones 10 Feb '11

10 Feb '11

Friends Just a heads-up. Pedro is working on implementing "Generic Defaults", as described in his Haskell Symposium 2010 paper www.dreixel.net/research/pdf/gdmh_nocolor.pdf It will replace (and improve on) the "Derivable type classes" stuff in GHC at the moment, which was originally presented in a paper of that title that Ralf and I wrote in the 2000 Haskell workshop http://research.microsoft.com/en-us/um/people/simonpj/papers/derive.htm. The "Derivable type class" extension is barely used, I believe, and isn't even documented in the manual. So I propose to switch from one to the other, rather than to try to support both. This change will happen in GHC 7.2 or 7.4, depending on when Pedro is done. Please yell if you are a secret user of derivable type classes, so this change would discombobulate you. Simon

4 5

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