- Glasgow-haskell-users

building ghc-6.8.2 network library fails under gcc43
by Jens Petersen 15 Feb '08

15 Feb '08

(I know gcc-4.3 is still under development, but it is expected to be the version of gcc in Fedora 9 which will be released around the end of April.) Has anyone tried or managed to build ghc with gcc-4.3? I tried yesterday in the Fedora buildsystem and got to: Socket.hsc: In function 'main': Socket.hsc:1144: error: invalid application of 'sizeof' to incomplete type 'struct ucred' Socket.hsc:1144: error: invalid application of 'sizeof' to incomplete type 'struct ucred' Socket.hsc:1144: error: invalid application of 'sizeof' to incomplete type 'struct ucred' Socket.hsc:1150: error: invalid use of undefined type 'struct ucred' Socket.hsc:1151: error: invalid use of undefined type 'struct ucred' Socket.hsc:1152: error: invalid use of undefined type 'struct ucred' Socket.hsc:2419: error: 'NI_MAXHOST' undeclared (first use in this function) Socket.hsc:2419: error: (Each undeclared identifier is reported only once Socket.hsc:2419: error: for each function it appears in.) Socket.hsc:2420: error: 'NI_MAXSERV' undeclared (first use in this function) compiling dist/build/Network/Socket_hsc_make.c failed command was: gcc -c -D__GLASGOW_HASKELL__=608 -I/builddir/build/BUILD/ghc-6.8.2/includes -I/builddir/build/BUILD/ghc-6.8.2/gmp/gmpbuild -D__GLASGOW_HASKELL__=608 -DCALLCONV=ccall -Iinclude dist/build/Network/Socket_hsc_make.c -o dist/build/Network/Socket_hsc_make.o Preprocessing library network-2.1.0.0... The full buildlog is at http://koji.fedoraproject.org/koji/getfile?taskID=425959&name=build.log Before investigating further I just wondered if anyone has already looked at this and might have a patch or workaround? Jens

2 1

GHC logo ideas (was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel))
by Tim Chevalier 15 Feb '08

15 Feb '08

On 2/14/08, Yitzchak Gale <gale(a)sefer.org> wrote: > Manuel M T Chakravarty wrote: > >> I'd also be nice to have a cool logo/icon. > > > Tim Chevalier wrote: > > I am a mediocre artist, but I'd be willing to give it a try if there > > are no better ones around. > > > Sounds great, please give it a whirl. > Well, I got bored in class, so here's a sketch: http://lafalafu.com/krc/Scratch/ghc-logo-idea.png This is still based on Yitzhak's idea of incorporating the Clyde Arc. The extra bit of the lambda that extends on the left and turns into a chip is meant to look like the bridge, though I'm not sure I got the shape right. I hereby release the above-linked image into the public domain. If anyone wants to mess with it or make something prettier that's based on the same idea, feel free. If anyone likes it, I could try to turn this into something more polished. I'm not sure to what extent GHC-land is crying out for a new logo, though... > > > I'm almost tempted to switch back to a Mac. > > > Since you have been a Mac user, you are aware of how > fidgety this platform is about aesthetics. We all appreciate Well, that was actually just in response to the "Installation instructions: nil" comment in the OP. I'd love to use something that has no installation instructions :-) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I do not write about nice people. I am not nice people." -- Dorothy Allison

2 1

Some problems writing a threaded program
by John Vogel 13 Feb '08

13 Feb '08

I am running my program in WinXP with ghc 2.6.8 If you install netstat and change the parameters it should still work in linux. Why does thread # 3 dominate over the over threads int the output? Why does thread # 4 never seem to run? I can't use the sleep function in System.Process.Win32 since it puts all the threads asleep at the same time. Is there a way to put only one thread asleep? That would allow more of a chance for thread #4 to run. The simplified program: --------------------------------------------------------------- module Main where import Data.IORef import Data.List import System.IO import System.Process import Control.Concurrent import Control.Concurrent.Chan data Connection = Null | Last | Active deriving (Eq) instance Show Connection where show Null = "Null" show Last = "Last" show Active = "Active" instance Read Connection where readsPrec _ s = case take 5 s of " UDP" -> [(Active, "")] " TCP" -> [(Active, "")] "Last" -> [(Last,"")] _ -> [(Null,"")] -- ptrints one 0 and 1 main = do stop <- newIORef False cbuffer <- newChan :: IO (Chan Connection) putStr "0" (_,output,_,ph) <- runInteractiveCommand "netstat -noa 5" sequence $ map forkIO $ [(processConnections ph output cbuffer), (stopNetstat ph stop False), (printChan cbuffer),(checkStop stop "xxxx")] putStr "1" _ <- waitForProcess ph --mapM killThread ts putStrLn "\nDone" -- thread # 2 processConnections :: ProcessHandle -> Handle -> (Chan Connection) -> IO () processConnections ph hout chan = do h <- hReady hout e <- getProcessExitCode ph putStr "2" if (not h && e /= Nothing) then do writeChan chan Last >> return () else do if h then do readConnection hout >>= writeChan chan else do processConnections ph hout chan readConnection :: Handle -> IO Connection readConnection hout = do l <- hGetLine hout let c = (read l :: Connection) if (c == Null) then do (readConnection hout) else do (return c) -- thread number 3 stopNetstat :: ProcessHandle -> (IORef Bool) -> Bool -> IO () stopNetstat netstat _ True = terminateProcess netstat stopNetstat netstat gref False = putStr "3" >> yield >> readIORef gref >>= stopNetstat netstat gref --thread 4 printChan :: (Chan Connection) -> IO () printChan chan = do putStr "4" c <- readChan chan printConnection c printChan chan checkStop :: (IORef Bool) -> String -> IO () checkStop ref s = do if (take 4 s == "stop") then do (writeIORef ref True) else do (getChar >>= (\x -> checkStop ref ((tail s) ++ [x]))) printConnection :: Connection -> IO () printConnection c = case c of Null -> putStr "N" Last -> putStr "L" _ -> putStr "A"

4 5

Array.ST is not being nice to me
by Robert van Herk 11 Feb '08

11 Feb '08

Hi all, I have a problem with regards to the speed of ST arrays. In short: a Data.Map.Map outperforms Data.Array.ST in my application, whereas as far as I understand it, the ST array should be quicker. My application is a compiler. It compiles some source code into a (huge) number of boolean equations. These equations are finally printed to stdout; they form my "byte-code". Also the equations are defined in terms of the other equations again. So, for instance, compiled byte code may look like: 1 == 5 5 == True /\ 3 3 == False To optimize the compiled code, I do some tricks like constant propagation. So, for instance, if I know that one equation always results in some constant, I substitute that constant for that equation. So above set of equations will be rewritten as: 1 == False 5 == False 3 == False ------ All in all, my compiler does the following: - It generates a set of equations for some statement in the source code - It rewrites these equations - It remembers for each equation which other equations it depends upon, such that if these are rewritten to something simple, this equation may be rewritten too. So there are a lot of lookups of the equations, especially for all the rewritings. All in all, I store quite some data for each equation, amongst which are: data EquationState = EQS {cDefinition::Equation, usedBy::Map.Map Int (), ...} First, I stored all the equations in a Data.Map.Map. Int EquationState. But then I thought it'd be more clever to put it into an ST array, seen the large number of lookups. So now i put it into an ST array. However, the code runs much, much slower now (about 4 times). The ST array does use slightly less memory though. I did some profiling. It seems that it is not the GC that is making over-hours. So my theory now is: I do a large number of lookups. Only a small number of these lookups trigger a change in the array. One EquationState is pretty big. Is it so that when you look something up from an ST array, the whole element gets deeply copied in memory, just in case you would change it in the array? Seen the size of my elements, I could imagine that that would cause a whole bunch of needless copying. Or is there some other reason for this slower behaviour of ST array? Robert

3 4

Shared Libraries in ghci
by Bernd Brassel 11 Feb '08

11 Feb '08

Sorry to ask a C question here, but I could not find an answer on the net. How do I create a library that can be used in ghci? This is the situation: I have a c file coracle.c. I do /tmp$ cc -c -o coracle.o coracle.c /tmp$ ar rc libcoracle.a coracle.o /tmp$ ranlib libcoracle.a and then I the library is linked statically with ghc just fine: /tmp$ ghc -L/tmp -lcoracle --make COracle.hs But if I create a shared library, like this: /tmp$ cc -c -shared -o libcoracle.so coracle.c then ghci does not like the format: /tmp$ ghci -L/tmp -lcoracle COracle.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading object (dynamic) coracle ... failed. Dynamic linker error message was: /tmp/libcoracle.so: only ET_DYN and ET_EXEC can be loaded Whilst trying to load: (dynamic) coracle Directories to search are: /tmp ghc-6.8.2: user specified .o/.so/.DLL could not be loaded. In the web I only find bla about which bit in the ELF-header of the library tells you that it is ET_DYN or not. But never how to build such a library. I guess it is too much to hope for a C-freak around here but I am sure a semi-freak or quarter-freak will do as well. Thanks in advance! Bernd

3 5

Internships at GHC HQ
by Simon Peyton-Jones 09 Feb '08

09 Feb '08

Would you be interested in working at Microsoft Research for three months? If so, you might want to think about applying for an internship. Simon and I are looking for interns, starting in summer 2008. Lots of background info here: http://hackage.haskell.org/trac/ghc/wiki/Internships including a bunch of possible projects, although you may also have ideas of your own. But the bottom line is - apply by end Feb 2008 for this round - tell one of us that you have done so (None of this is restricted to Haskell stuff. You can apply to work at any Microsoft Research lab, on any topic. But there are a lot of applicants, so you are more likely to be successful if you are fairly specific about who at MSR you'd like to work with and why, and contact that person to say that you've applied.) Simon

2 1

What does unsafePerformIO do to the stack
by Bernd Brassel 08 Feb '08

08 Feb '08

Consider the following program: module Stack where import System.IO.Unsafe main = print (sim (replicate 1299959 ())) sim [] = True sim (_:xs) = goodStack (sim xs) goodStack x = fromJust (Just x) --no stack overflow badStack x = unsafePerformIO (return x) --stack overflow fromJust (Just x) = x I always thought that unsafePerformIO would do something similar as goodStack. i.e. be stack neutral: $ ghc --make -o stack Stack [1 of 1] Compiling Main ( Stack.hs, Stack.o ) Linking stack ... $ stack +RTS -K0.00001M True But if you exchange goodStack with badStack, the picture changes unfortunately to: $ ghc --make -o stack Stack [1 of 1] Compiling Main ( Stack.hs, Stack.o ) Linking stack ... $ stack +RTS -K9.883647M Stack space overflow: current size 9883644 bytes. Use `+RTS -Ksize' to increase it. $ stack +RTS -K9.883648M True I am using: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 Is this behaviour necessary? Is there any work around, e.g., employing the foreign function interface? Thanks for your time! Bernd

2 8

Will implicit parameters survive?
by Wolfgang Jeltsch 07 Feb '08

07 Feb '08

Hello, what are the plans for implicit parameters? Will GHC continue to support them or could it be that they will be removed at some time? I think that implicit parameters can be very useful for implementing global variables as described in <http://www.cs.chalmers.se/~rjmh/Globals.ps>. Surprisingly, the interest in implicit parameters seems to be rather low as the GHC survey from 2005 suggests. Despite this, I’d propose that support for implicit parameters continues. But what do the GHC developers think? Best wishes, Wolfgang

3 2

Re: GHC armel port for N810
by Dustin DeWeese 07 Feb '08

07 Feb '08

Martin, I was able to make an unregisterised port of GHC 6.8.2 to the N810 by using Scratchbox with the qemu-arm-eabi patch[1]. Have you started on a registerised port? I have been reading the ARM Architecture Reference Manual and other documents about the ARM ABI, and I am working on a registerised port of GHC for the N810. [1] http://maemogeek.blogspot.com/2007/11/installing-qemu-arm-eabi-patch-into.h… On Jan 23, 2008 7:32 AM, Martin Guy <martinwguy(a)yahoo.it> wrote: > > I've been working on porting GHC to armel for the Nokia N810. > > Unfortunately, I can't use the packages you made because the OS > > (maemo.org) is based on Debian Sarge and uses libc-2.5. I'm using > > scratchbox (scratchbox.org) and qemu and following the instructions at > > http://hackage.haskell.org/trac/ghc/wiki/Building/Porting , but have > > been unsuccessful. The stage1 compiler compiles fine, but then crashes > > when building the stage2 compiler on qemu. I've tried GHC 6.4.2, 6.6.1, > > and 6.8.2, but 6.6.1 is the version I get furthest with. Is there any > > tips you can give me? Do you still have the intermediate .hc files from > > your builds? (The .hc files built on a ARM might work better.) Did you > > have similar problems with qemu? > > I used a fast x86 to make the .hc files, as documented in the URL you > cite, > then did the final build on a lot of real ARMs. The problem is it > needs over 128MB RAM (yes, RAM) to compile some of the files - I did > these few under QEMU. My personal notes are attached - these are not a > product, they are my own personal notes, so please don't expect them > to be a how-to. Porting GHC was difficult and not straightforward, > dying at many stages for many different reasons. > > The real answer is for Maemo to update its software to versions from > this century. > I did this in 2006 trying to bootstrap the Debian arm EABI port and my > notes are at > http://cluster.aleph1.co.uk/~martin/maemo-fixes.txt<http://cluster.aleph1.co.uk/%7Emartin/maemo-fixes.txt> > > For further help with this, I suggest we find a mailing list where > others can give their expertise and experience, and where in future > people will find the outcome of our discussion. How about > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ? > > Good luck! > > M >

1 0

GHC lazy eval optimization bug
by Adam P Jenkins 05 Feb '08

05 Feb '08

The haskell program below demonstrates an optimization bug with the GHC compiler. I have tried this with ghc 6.8.1 on my MacBook Pro and on a Linux i686 machine. This email should build as a literate haskell program. Build the program as ghc --make -O lazyevalbug.lhs and run it with no arguments. An IO action runs 4 times, printing out how long it took each time. It takes 1 to 2 seconds to run each time, but it should only take 1 second or 2 the first time, and finish almost instantaneously the rest of the times. If you run the program with "fast" as a cmdline arg, as in ./lazyevalbug fast then it will behave how I'd expect it to: the first IO action takes a couple of seconds tand the rest finish instantaneously. If you build the program without the -O switch, then it behaves the same with our without the "fast" commandline arg. DETAILS: The bug involves lazy evalutation behaving in an unexpected way when the program is compiled with the -O switch. If I create an IO action which refers to a variable which was defined outside of the IO action, and then run that IO action multiple times, then in some circumstances the variable value will be re-computed each time the IO action is run. This seems to violate the behavior I expect from lazy evaluation. I.e. if I have code like this: let val = really_expensive_computation in map (\x -> val + x) [1, 2, 3] I would expect val to only be computed once. And it is. However if instead of referring to val in a lambda function I refer to val from an IO action, then in some cases it seems to be re-evaluated every time the action is performed. I.e. let val = really_expensive_computation in replicateM_ 3 (print val) When compiled with -O, the above will recompute val 3 times. However adding a second reference to "val" seems to make the problem go away. Another thing I noticed is, the problem seems to only occur if really_expensive_computation involves the IO monad somehow, for example if it's doing a computation based on some input read from stdin. If really_expensive_computation only involves data generated within the program then the bug never occurs. The program below demonstrates this problem with the doSlow and doFast functions. See the comment above these functions. Also, in main, if you comment out the getStdGen line and uncomment the mkStdGen line, then the problem goes away. This demonstrates the fact that if the computation uses data from an IO action the problem occurs, otherwise it doesn't. > import System (getArgs) > import qualified System.Time as ST > import Control.Monad (when, replicateM_) > import System.Random (getStdGen, mkStdGen, randoms) Takes an IO action, runs it, and prints line saying how long it took to run > timeIt :: IO a -> IO () > timeIt action = > do tic <- ST.getClockTime > action > toc <- ST.getClockTime > putStrLn $ "Took " ++ (timeDiffToString (ST.diffClockTimes toc tic)) > -- System.Time.timeDiffToString doesn't handle fractions of a > -- second correctly, so I implement my own version > where timeDiffToString d = > let secs = ST.tdMin d * 60 + ST.tdSec d > frac = (realToFrac $ abs $ ST.tdPicosec d) / (realToFrac $ 10^12) > in show ((realToFrac secs) + frac) ++ " secs" True if a number is prime. Just a function meant to use up some time > isPrime :: (Integral n) => n -> Bool > isPrime n = > let lim = round (sqrt $ realToFrac n) in > not $ any (\x -> n `rem` x == 0) [2..lim] doSlow and doFast are exactly the same, except that doFast has an extra "when" statement which references "primes". The mere existence of this extra reference to "primes" in doFast seems to cause the primes list to only be generated once, so the first time action runs takes around 1.6 seconds, but subsequent actions finish in a small fraction of a second. In doSlow, the action takes 1.6 seconds each time it runs, not just the first time, indicating that primes is getting re-created each time the action is run. > doSlow, doFast :: (Integral a) => [a] -> IO () > doSlow lst = let primes = filter isPrime lst > action = timeIt $ print (length primes) > in do replicateM_ 4 action > doFast lst = let primes = filter isPrime lst > action = timeIt $ print (length primes) > in do replicateM_ 4 action > when (null primes) (print "No primes") In main, comment out the getStdGen line and uncomment the mkStdGen line and the problem goes away as well. The same is true if I read data from stdin vs generating a list in memory. > main = do args <- getArgs > let doFunc = if (length args) > 0 && args!!0 == "fast" > then doFast > else doSlow > --gen <- return $ mkStdGen 42 > gen <- getStdGen > let lst = take 10000 $ randoms gen :: [Integer] > doFunc lst

5 6