February 2005 - Glasgow-haskell-users

Re: Bug#294481: ghci -lpthread fails
by Ian Lynagh 10 Feb '05

10 Feb '05

On Wed, Feb 09, 2005 at 11:13:36PM +0100, Juliusz Chroboczek wrote: > Package: ghc6 > Version: 6.2.2-2 > > /usr/lib/libpthread.so (comes from libc6-dev 2.3.2.ds1-20) is a GNU > linker script, not a shared object. This breaks ghci. Known problem: http://www.haskell.org/pipermail/glasgow-haskell-users/2004-May/006671.html What is your particular problem? CCing glasgow-haskell-users(a)haskell.org as someone there may have an answer, or be interested to know the problem exists if not. Thanks Ian

3 3

RE: Unregistering a package
by Simon Marlow 10 Feb '05

10 Feb '05

On 09 February 2005 13:32, Peter Simons wrote: > I have an interesting problem. There are two versions of the > HsDNS package installed right now: > > $ ghc-pkg list > | /usr/local/ghc-current/lib/ghc-6.5/package.conf: > | rts-1.0, [...] (hsdns-2005-02-04), > | hsdns-2005-02-08 > > Now how can I unregister them? I have tried everything I > could think of, but no luck: > > $ ghc-pkg unregister hsdns > | ghc-pkg: package hsdns matches multiple packages: > | hsdns-2005-02-04, hsdns-2005-02-08 > > $ ghc-pkg unregister hsdns-2005-02-08 > | ghc-pkg: cannot parse 'hsdns-2005-02-08' as a package identifier > > Can someone give me a pointer how to remedy this situation? The problem is not really that "hsdns-2005-02-08" isn't a legal package identifier, actually it is an ambiguous package identifier. I suggest you remove that package by hand from the package.conf file, and instead use "hsdns-2005.02.08". The general syntax of package ids is: pkgid ::= pkg ('-' version)? pkg ::= (alphanum|'-')+ version ::= (digit+) ('.' digit+)* ('-' alphanum+)* This syntax means that package ids which have numeric component(s) at the end and no '.' will be ambiguous. I've added a test to ghc-pkg to prevent you from registering a package with a problematic package id for now. Perhaps we should change the syntax of package ids though? Cheers, Simon

2 1

Haddock issue
by Luis F. Araujo 10 Feb '05

10 Feb '05

Hello everyone, I was getting the following error with 'make html' : /usr/bin/haddock -t "Haskell Hierarchical Libraries (template-haskell package)" -h -o html Language/Haskell/TH.raw-hs Language/Haskell/TH/Lib.raw-hs Language/Haskell/TH/Ppr.raw-hs Language/Haskell/TH/PprLib.raw-hs Language/Haskell/TH/Syntax.raw-hs \ --package=template-haskell \ --dump-interface=template-haskell.haddock \ --use-index=../doc-index.html --use-contents=../index.html \ --read-interface=../base,../base/base.haddock Language/Haskell/TH/Syntax.raw-hs:156:1: parse error in doc string: [TokString " monad.\n",TokString "Take care: you are guaranteed the ordering of calls to ",TokIdent [runIO]] make[2]: *** [html/haddock.css] Error 1 make[1]: *** [html] Error 1 make: *** [html] Error 1 Apparently haddock needs to see I\/O instead of I/O in the line 149 of libraries/template-haskell/Language/Haskell/TH/Syntax.hs . Anyone is aware of this problem? Cheers,

1 0

RE: GHC 6.4 release candidates available
by Simon Marlow 10 Feb '05

10 Feb '05

On 10 February 2005 15:36, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> Ok, fixed. The right way to get the location of the package.conf >> file is to ask ghc-pkg, BTW. In fact, the right way is not to know >> the location of package.conf at all, but to use ghc-pkg to query its >> contents. The contents of package.conf is proprietary :-) > > And indeed hmake does use ghc-pkg, when it needs to find import > directories etc. But the thing is, previous versions of ghc-pkg > reported such directories as e.g. "$libdir/base", and how do you find > out what $libdir refers to...? ghc --print-libdir Cheers, Simon

2 1

RE: GHC 6.4 release candidates available
by Simon Marlow 10 Feb '05

10 Feb '05

On 10 February 2005 15:13, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> We are finally at the release candidate stage for GHC 6.4. >> Please test if you're able to, and give us feedback. > > In versions 5.00 <= ghc <= 6.2.2, the result of > > ghc -v 2>&1 | head -2 > > was something like > > Glasgow Haskell Compiler, Version 6.2.2, .... > Using package config file: /grp/haskell/lib/ghc-6.2.2/package.conf > > whereas with 6.4, these two lines have been swapped: > > Reading package config file: > /usr/malcolm/local/lib/ghc-6.4.20050209/package.conf Glasgow > Haskell Compiler, Version 6.4.20050209, .... > > and the "Using package config" message has become "Reading package > config". These changes are minor and unnecessary: in particular they > make the detection of configuration information (by hmake) rather > more complicated than it ought to be. I know this is a pretty trivial > complaint, but the -v behaviour has been stable for a few years now, > so why change it arbitrarily? Ok, fixed. The right way to get the location of the package.conf file is to ask ghc-pkg, BTW. In fact, the right way is not to know the location of package.conf at all, but to use ghc-pkg to query its contents. The contents of package.conf is proprietary :-) Cheers, Simon

2 1

RE: GHC 6.4 release candidates available
by Simon Marlow 10 Feb '05

10 Feb '05

On 10 February 2005 13:40, Simon Marlow wrote: > On 10 February 2005 13:31, Malcolm Wallace wrote: > >> "Simon Marlow" <simonmar(a)microsoft.com> writes: >> >>> We are finally at the release candidate stage for GHC 6.4. >>> Snapshots with versions 6.4.20050209 and later should be considered >>> release candidates for 6.4. >> >> Using: ghc-6.4.20050209-i386-unknown-linux.tar.bz2 >> >> $ cat hello.hs >> main = putStrLn "hello world" >> $ ghc--6.4.20050209 -o hello hello.hs >> ld: cannot find -lHSbase_cbits >> collect2: ld returned 1 exit status >> $ >> >> Pretty much a show-stopper. > > Yes, I'm fixing this right now. Please hold off downloading until I > can get a fixed distribution up... New distributions are up now. Cheers, Simon

1 0

RE: GHC 6.4 release candidates available
by Simon Marlow 10 Feb '05

10 Feb '05

On 10 February 2005 13:31, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> We are finally at the release candidate stage for GHC 6.4. Snapshots >> with versions 6.4.20050209 and later should be considered release >> candidates for 6.4. > > Using: ghc-6.4.20050209-i386-unknown-linux.tar.bz2 > > $ cat hello.hs > main = putStrLn "hello world" > $ ghc--6.4.20050209 -o hello hello.hs > ld: cannot find -lHSbase_cbits > collect2: ld returned 1 exit status > $ > > Pretty much a show-stopper. Yes, I'm fixing this right now. Please hold off downloading until I can get a fixed distribution up... Cheers, Simon

1 0

RE: ghc sensitive to struct layout
by Simon Marlow 10 Feb '05

10 Feb '05

On 09 February 2005 08:53, Axel Simon wrote: > gcc uses a different convention from the Microsoft environment when it > comes to laying out fields in C structs, in particular bit fields. > Can I pass the -optc--mms-bitfields to ghc when it compiles via C > without negative effect? > > This flag is not implicit at the moment which I assume means that ghc > itself is not compiled with --mms-bitfields on Windows. ghc surely > includes struct declarations when it compiles the generated C files, > so the question is whether all its structs are laid out the same > regardless of which layout option one chooses. The answer is I don't know, but we could probably make it true if necessary. In GHC 6.4, the generated HC code doesn't use any structs, all the field offests are precomputed, which will no doubt make your life easier. One thing you could do (in 6.4) is to compile ghc/include/mkDerivedConstants.c with and without -mms-bitfields and see if it generates the same output. If it does, then we have some confidence that -mms-bitfields won't cause any grief. If it doesn't, then we have some clue about what needs fixing. Cheers, Simon

1 0

RE: Download stats
by Simon Marlow 10 Feb '05

10 Feb '05

On 09 February 2005 20:03, Tomasz Zielonka wrote: > On Wed, Feb 09, 2005 at 01:11:34PM -0000, Simon Marlow wrote: >> Hi folks, >> >> For the forthcoming 6.4 release, we'd like to get a rough idea of >> download statistics, at least from haskell.org. Both Simon & I are >> too busy/lazy (delete as applicable) to do this ourselves, and we >> don't know the best tools to use (grep|wc on the access_log is a bit >> too crude - we want to exclude things like partial downloads except >> when the download was completed later, etc.). Of course, if we can >> get or estimate download statistics for other sources of GHC too, >> that would be great. >> >> Any volunteers? > > Why not ask GHC users to fill some web form with additional > information, like how they use GHC, where they use it, for what, etc? > > I can make a suitable web form in WASH, if you want. That would be nice. There's no way I'm putting a web form in the way of the download link, but having it a separate "survey" on the site would perhaps be useful. Cheers, Simon

1 0

debugging memory allocations
by Duncan Coutts 09 Feb '05

09 Feb '05

All, I'm looking for advice on how to figure out why some piece of code is allocating memory when I think it ought to be able to work in constant space. In these cases we cannot turn on traditional profiling since that would interfere with the optimisations we are relying on to eliminate most of the other memory allocations. Would looking at the core files help? What would I be looking for? Here's a simple version that I would expect to run in constance space. pixbufSetGreen :: Pixbuf -> IO () pixbufSetGreen pixbuf = do ptr <- pixbufGetPixels pixbuf sequence_ [ do pokeByteOff ptr (y*384+3*x) (0 ::Word8) pokeByteOff ptr (y*384+3*x+1) (128::Word8) pokeByteOff ptr (y*384+3*x+2) (96 ::Word8) | y <- [0..127] , x <- [0..127] ] (Don't worry about all those random constants, it's just test code!) I thought this might be the case since in ghc's Data.Array.Base we have some similar style code: {-# INLINE newArray #-} -- The INLINE is crucial, because until we know at least which monad -- we are in, the code below allocates like crazy. So inline it, -- in the hope that the context will know the monad. newArray (l,u) init = do marr <- newArray_ (l,u) sequence_ [unsafeWrite marr i init | i <- [0 .. rangeSize (l,u) - 1]] return marr Note of course that in my example we know exactly which monad we're using. Here is the real example code I was writing when I found that it was using lots of cpu cycles and +RTS -B -RTS beeps lots and lots. Compiled using -O (-O2 is the same) -fglasgow-exts with ghc-6.2.2. pixbufSetPixelsRGB8 :: Pixbuf -> (Int -> Int -> (# Word8, Word8, Word8 #)) -> IO () pixbufSetPixelsRGB8 pixbuf setPixel = do -- TODO assert that the format is RGB8 rowStride <- pixbufGetRowstride pixbuf width <- pixbufGetWidth pixbuf height <- pixbufGetHeight pixbuf let loop ptr y | y == height = return () | otherwise = do let rowLoop ptr x | x == width = return () | otherwise = case setPixel x y of (# red, green, blue #) -> do pokeByteOff ptr 0 red pokeByteOff ptr 1 green pokeByteOff ptr 2 blue rowLoop (ptr `plusPtr` 3) (x+1) rowLoop ptr 0 loop (ptr `plusPtr` rowStride) (y+1) pixelsPtr <- pixbufGetPixels pixbuf loop pixelsPtr 0 It was being called like so: setWierdColour :: Int -> Pixbuf -> IO () setWierdColour counter pixbuf = let val = fromIntegral counter in pixbufSetPixelsRGB8 pixbuf (\x y -> (# fromIntegral x + val , fromIntegral y + val , fromIntegral x + fromIntegral y + val #)) Duncan

2 3