- Glasgow-haskell-users

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

Download stats
by Simon Marlow 09 Feb '05

09 Feb '05

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? Cheers, Simon

4 3

Unregistering a package
by Peter Simons 09 Feb '05

09 Feb '05

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? Peter

1 0

ghc sensitive to struct layout
by Axel Simon 09 Feb '05

09 Feb '05

Good morning, 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. Thank, Axel.

1 0

GHC as a package
by Lennart Kolmodin 08 Feb '05

08 Feb '05

Hi! I'm working on an IDE for Haskell, written in Haskell. Currently, I'm looking for a way to parse .hs-files for a module browser and I recall that Simon Marlow was going to release GHC as a package "soon". We could also use that package to compile source code without invoking ghc as a separate process. What is the status of the package and where can I get it? I can't find it in the CVS or in any of the snapshots. /Lennart

1 0

RE: ghc-cvs-snapshot with wxHaskell
by Simon Marlow 08 Feb '05

08 Feb '05

On 07 February 2005 19:28, Patrick Scheibe wrote: > It seems that there are changes in the OpenGl library during the last > month. So I decided to load a really young cvs version of the ghc > (ghc-6.5.20050206-src.tar.bz2). The compilation works fine. > > My Problem is, that I also need the wxHaskell library. This > compilation fails with the message: > > <wxoutput> > ghc -c wxdirect/src/Map.hs -o out/wxdirect/Map.o -ohi > out/wxdirect/Map.hi -odir out/wxdirect/ -package parsec > -iout/wxdirect > sed: kann out/wxdirect/Map.d.in nicht lesen: Datei oder Verzeichnis > nicht gefunden > make: *** [out/wxdirect/Map.o] Fehler 2 > </wxoutput> > > The third line is german and means "sed: unable to read > out/wxdirect/Map.d.in: File not found". > This or an almost similar error appears when I use the cvs version of > wxhaskell. > > I'm also in contact with Daan Leijen, the main developer of wxHaskell. > He said: > > <daan> > Darn, it seems that ghc changed its options or something. My makefile > generates dependency files (".d" files) using ghc. Since "sed" can't > find the file, it is either not generated or it is put at the wrong > directory. Can you look around in your file system if there is a Map.d > or Map.d.in file somewhere around (maybe Map.hs.d.in ?) I guess it > is still in the source directory instead of the out/... directory. Could you tell us what command line was supposed to generate the Map.d.in or Map.d file? It may be a bug, there were a few changes in the driver recently. Cheers, Simon

2 1

ghc-cvs-snapshot with wxHaskell
by Patrick Scheibe 07 Feb '05

07 Feb '05

Hi, It seems that there are changes in the OpenGl library during the last month. So I decided to load a really young cvs version of the ghc (ghc-6.5.20050206-src.tar.bz2). The compilation works fine. My Problem is, that I also need the wxHaskell library. This compilation fails with the message: <wxoutput> ghc -c wxdirect/src/Map.hs -o out/wxdirect/Map.o -ohi out/wxdirect/Map.hi -odir out/wxdirect/ -package parsec -iout/wxdirect sed: kann out/wxdirect/Map.d.in nicht lesen: Datei oder Verzeichnis nicht gefunden make: *** [out/wxdirect/Map.o] Fehler 2 </wxoutput> The third line is german and means "sed: unable to read out/wxdirect/Map.d.in: File not found". This or an almost similar error appears when I use the cvs version of wxhaskell. I'm also in contact with Daan Leijen, the main developer of wxHaskell. He said: <daan> Darn, it seems that ghc changed its options or something. My makefile generates dependency files (".d" files) using ghc. Since "sed" can't find the file, it is either not generated or it is put at the wrong directory. Can you look around in your file system if there is a Map.d or Map.d.in file somewhere around (maybe Map.hs.d.in ?) I guess it is still in the source directory instead of the out/... directory. If it is not generated at all, things become more complicated .. </daan> Can anyone give a hint or knows the problem/change in the new ghc. Currently I'm working with ghc-6.2.1. Another solution is to get the OpenGl branch of the library path running with my old ghc. I tried it in my primitive and simple way and just copied the new OpenGL directory into my old source of ghc and recompiled it. The library fails to compile. Cheers Patrick

1 0