- Glasgow-haskell-users

Hackage buildbot: llvm
by Christian Hoener zu Siederdissen 30 Mar '11

30 Mar '11

Hi, could it be that the llvm version used for the hackage buildbot is too old? The newest version of my 'Biobase' library does not compile there: http://hackage.haskell.org/packages/archive/Biobase/0.3.1.0/logs/failure/gh… and this seems to be due to llvm being too old: http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/19397 Gruss, Christian Options in my cabal file (for reference): ghc-options: -Odph if impl(ghc > 6.13) ghc-options: -fllvm

1 0

warning
by Luca Ciciriello 29 Mar '11

29 Mar '11

Hi All. I've installed on my MacOS X 10.6.7 (Xcode4) the new GHC 7.0.3 (64 bit) All works fine, but every time I build my code I get the warning: ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame Is this warning something bad? Thanks. Luca.

1 0

Fix context reduction stack overflow in dimensional
by Bas van Dijk 29 Mar '11

29 Mar '11

Dear Bjorn, Attached is a patch that fixes a context reduction stack overflow in your dimensional package. I noticed something weird though (that's why I'm CCing the ghc list). When I cabal build dimensional-0.8.2 I first get the context reduction stack overflow when I then build it again I get the error again (as expected). However when I try to build it for the third time it succeeds! Why is this? I attached the build log. Regards, Bas

3 3

OPTIONS_GHC -prof -auto-all
by Henning Thielemann 28 Mar '11

28 Mar '11

I have a large package and want to profile all functions of a single module of that package. I tried to prepend the pragma {-# OPTIONS_GHC -prof -auto-all #-} to the mentioned module, but GHC rejects this, because the profiler options are not allowed in the OPTIONS pragma. According to http://www.haskell.org/pipermail/glasgow-haskell-users/2006-December/011701… this is a known issue. I could certainly add GHC-Options: -prof -auto-all to the package Cabal description, but I expect this would add cost centres to all functions in all modules of the package. I could add SCC pragmas to all top-level functions in the profiled module, but this is cumbersome. Thus my question: Is there a straightforward way to add cost centres to all functions of a single module in a Cabal package?

2 1

downgrade HP
by Luca Ciciriello 26 Mar '11

26 Mar '11

Hi All. How can I downgrade the Haskell platform from 2011.2.0.0 to 2010.2.0.0? I've removed the HP 2011.2.0.0 and installed again the HP 2010.2.0.0, but now several important packages (like IO) are missing! My system is MacOS X 10.6.7 with Xcode 4 installed. Any idea? Thanks in advance. Luca.

1 0

Issue with SrcSpan of AbsBinds
by JP Moresmau 25 Mar '11

25 Mar '11

Hello, I'm trying to get Scion to work well with GHC7, and I found a small issue (I'm not saying it's GHC7 only, maybe it was there in GHC 6.12). I'm using 7.0.2 I have the following code, which is idiotic but proves the point: fun :: t -> [Char] -> [Char] fun _=reverse . map toUpper And the TypecheckedSource gives me something like (using the ghc-syb-utils package to dump it:) {Bag(Located (HsBind Var)): [ (L {src\Folder1\ForAll.hs:8:1-29} (AbsBinds [{Var: t}] [] [ ((,,,) [{Var: t}] {Var: Folder1.ForAll.fun} {Var: fun} (SpecPrags []))] ({abstract:TcEvBinds}) {Bag(Located (HsBind Var)): [ (L {src\Folder1\ForAll.hs:9:1-27} (FunBind (L {src\Folder1\ForAll.hs:9:1-3} {Var: fun}) (False) (MatchGroup Obviously my code starts at line 8 in that example. The issue occurs when the scion code wants to tell the user what (name+type) is a particular line/column in the source Now the scion code does something simple: to find something at a given point, it goes down the tree, and when it encounters a Located object, it checks the location spans around the point we're looking at. The issue here is that the AbsBinds has a SrcSpan that only covers the type signature, and not the rest of the code, hence (I think) we never go down the contents, and Scion cannot resolve anything when a user asks it to. If the type signature is not present, the problem doesn't occur: the AbsBinds location covers all the source code. If the type signature is present but without any type variable, there is no AbsBinds and no problem. Is that normal behavior, and hence should I code a work around in Scion? Thanks! -- JP Moresmau http://jpmoresmau.blogspot.com/

3 2

Re: ghc fails with HOME not set, fixing right now
by Christian Maeder 25 Mar '11

25 Mar '11

ghc should not fail if HOME is not set. It certainly cannot look up local packages then, but ghc should work without those, too. ghc is a compiler like gcc. Does gcc need HOME? Cheers Christian Am 25.03.2011 08:26, schrieb Joachim Breitner: > Hi, > > new FTBFS coming up: ghc fails if HOME is not set, which is apparently > the case on some buildds. I’m now setting HOME to a dummy variable in > debian/rules and building it right now in a pbuilder (with HOME not > set...). > > We’ll need to see if this affects the libraries as well. If that is the > case, it can be easily fixed in haskell-devscripts. > > Greetings, > Joachim >

2 1

7.0.3
by Ian Lynagh 24 Mar '11

24 Mar '11

Hi all, Due to a number of issues in the 7.0.2 release, we plan to put out a 7.0.3 release before finally retiring the 7.0 branch. We intend to fix: * Doc install location on Windows * Doc building on OS X (#4997) * Object splitting on OS X (with XCode >= 3.2) * Don't require the 10.5 SDK on OS X (should mean GHC works with XCode 4) We will also look into the problems with stripping and libHSghc.a (e.g. the issue building yesod #5004), and the ld warnings on OS X (#4984). We want to keep the changes in this release to a minimum, to minimise the chance of regressions, but if you think we've missed any critical issues please let us know. Thanks Ian

7 8

Re: memory slop (was: Using the GHC heap profiler)
by John Lato 22 Mar '11

22 Mar '11

Minor update, here's how I would handle this problem (using uu-parsinglib and the latest ListLike, mostly untested): import Data.ListLike (fromString, CharString (..)) import Text.ParserCombinators.UU import Text.ParserCombinators.UU.BasicInstances import Text.ParserCombinators.UU.Utils -- change the local bindings in undumpFile to: addv m s | BS.null s = m addv m s = let (k,v) = readKV s in Map.insert k v m readKV :: BS.ByteString -> (BS.ByteString, BS.ByteString) readKV s = let [ks,vs] = parse (pTuple [pQuotedString, pQuotedString]) (createStr (LineColPos 0 0 0) $ CS s) unCSf = BS.drop 1 . BS.init . unCS in (unCSf ks, unCSf vs) And of course change the type of "foldLines" and use BS.hGetLine, both to enable ByteString IO. To use uu-parsinglib's character parsers (e.g. pTuple) with ByteStrings, you need to use a newtype wrapper such as CharString from ListLike, "CS" and "unCS" wrap and unwrap the type. The "unCSf" function removes the starting and trailing quotes in addition to unwrapping. This is still quick-and-dirty in that there's no error recovery, but it's easy to add, just see the uu-parsinglib documentation and examples, particularly "pEnd". I think this will make a significant difference to your application. John L. Message: 4 > Date: Tue, 22 Mar 2011 20:32:16 -0600 > From: Tim Docker <twd2(a)dockerz.net> > Subject: memory slop (was: Using the GHC heap profiler) > To: glasgow-haskell-users(a)haskell.org > Message-ID: <4D895BB0.1080902(a)dockerz.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > -------- Map2.hs -------------------------------------------- > > module Main where > > import qualified Data.Map as Map > import qualified Data.ByteString.Char8 as BS > import System.Environment > import System.IO > > type MyMap = Map.Map BS.ByteString BS.ByteString > > foldLines :: (a -> String -> a) -> a -> Handle -> IO a > foldLines f a h = do > eof <- hIsEOF h > if eof > then (return a) > else do > l <- hGetLine h > let a' = f a l > a' `seq` foldLines f a' h > > undumpFile :: FilePath -> IO MyMap > undumpFile path = do > h <- openFile path ReadMode > m <- foldLines addv Map.empty h > hClose h > return m > where > addv m "" = m > addv m s = let (k,v) = readKV s > in k `seq` v `seq` Map.insert k v m > > readKV s = let (ks,vs) = read s in (BS.pack ks, BS.pack vs) > > dump :: [(BS.ByteString,BS.ByteString)] -> IO () > dump vs = mapM_ putV vs > where > putV (k,v) = putStrLn (show (BS.unpack k, BS.unpack v)) > > main :: IO () > main = do > args <- getArgs > case args of > [path] -> do > v <- undumpFile path > dump (Map.toList v) > return () >

1 0

Re: memory slop (was: Using the GHC heap profiler)
by John Lato 22 Mar '11

22 Mar '11

Hi Tim, Sorry I can't tell you more about slop (I know less than you at this point), but I do see the problem. You're reading each line from a Handle as a String (bad), then creating ByteStrings from that string with BS.pack (really bad). You want to read a ByteString (or Data.Text, or other compact representation) directly from the handle without going through an intervening string format. Also, you'll be better off using a real parser instead of "read", which is very difficult to use robustly. John L. > From: Tim Docker <twd2(a)dockerz.net> > Subject: memory slop (was: Using the GHC heap profiler) > To: glasgow-haskell-users(a)haskell.org > Message-ID: <4D895BB0.1080902(a)dockerz.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > On Mon, Mar 21, 2011 at 9:59 AM, I wrote: > > > > My question on the ghc heap profiler on stack overflow: > > > > > http://stackoverflow.com/questions/5306717/how-should-i-interpret-the-outpu… > > > > remains unanswered :-( Perhaps that's not the best forum. Is there > someone > > here prepared to explain how the memory usage in the heap profiler > relates > > to the "Live Bytes" count shown in the garbage collection statistics? > > I've made a little progress on this. I've simplified my program down to > a simple executable that loads a bunch of data into an in-memory map, > and then writes it out again. I've added calls to `seq` to ensure that > laziness is not causing excessing memory consumption. When I run this on > my sample data set, it takes ~7 cpu seconds, and uses ~120 MB of vm An > equivalent python script, takes ~2 secs and ~19MB of vm :-(. > > The code is below. I'm mostly concerned with the memory usage rather > than performance at this stage. What is interesting, is that when I turn > on garbage collection statistics (+RTS -s), I see this: > > 10,089,324,996 bytes allocated in the heap > 201,018,116 bytes copied during GC > 12,153,592 bytes maximum residency (8 sample(s)) > 59,325,408 bytes maximum slop > 114 MB total memory in use (1 MB lost due to fragmentation) > > Generation 0: 19226 collections, 0 parallel, 1.59s, 1.64selapsed > Generation 1: 8 collections, 0 parallel, 0.04s, 0.04selapsed > > INIT time 0.00s ( 0.00s elapsed) > MUT time 5.84s ( 5.96s elapsed) > GC time 1.63s ( 1.68s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 7.47s ( 7.64s elapsed) > > %GC time 21.8% (22.0% elapsed) > > Alloc rate 1,726,702,840 bytes per MUT second > > Productivity 78.2% of total user, 76.5% of total elapsed > > This seems strange. The maximum residency of 12MB sounds about correct > for my data. But what's with the 59MB of "slop"? According to the ghc docs: > > | The "bytes maximum slop" tells you the most space that is ever wasted > | due to the way GHC allocates memory in blocks. Slop is memory at the > | end of a block that was wasted. There's no way to control this; we > | just like to see how much memory is being lost this way. > > There's this page also: > > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/Slop > > but it doesn't really make things clearer for me. > > Is the slop number above likely to be a significant contribution to net > memory usage? Are there any obvious reasons why the code below could be > generating so much? The data file in question has 61k lines, and is <6MB > in total. > > Thanks, > > Tim > > -------- Map2.hs -------------------------------------------- > > module Main where > > import qualified Data.Map as Map > import qualified Data.ByteString.Char8 as BS > import System.Environment > import System.IO > > type MyMap = Map.Map BS.ByteString BS.ByteString > > foldLines :: (a -> String -> a) -> a -> Handle -> IO a > foldLines f a h = do > eof <- hIsEOF h > if eof > then (return a) > else do > l <- hGetLine h > let a' = f a l > a' `seq` foldLines f a' h > > undumpFile :: FilePath -> IO MyMap > undumpFile path = do > h <- openFile path ReadMode > m <- foldLines addv Map.empty h > hClose h > return m > where > addv m "" = m > addv m s = let (k,v) = readKV s > in k `seq` v `seq` Map.insert k v m > > readKV s = let (ks,vs) = read s in (BS.pack ks, BS.pack vs) > > dump :: [(BS.ByteString,BS.ByteString)] -> IO () > dump vs = mapM_ putV vs > where > putV (k,v) = putStrLn (show (BS.unpack k, BS.unpack v)) > > main :: IO () > main = do > args <- getArgs > case args of > [path] -> do > v <- undumpFile path > dump (Map.toList v) > return () >

1 0