March 2003 - Glasgow-haskell-users

RE: 5.04.2 RPM Dependencies
by Simon Marlow 11 Mar '03

11 Mar '03

> On 2003-03-10 at 20:57GMT "Dominic Steinitz" wrote: > > Can anyone help? I downloaded the latest rpm for ghc but > got the following > > errors on installation: > > > > error: failed dependencies: > > libc.so.6(GLIBC_2.3) is needed by ghc-5.04.2-1 > > libreadline.so.4 is needed by ghc-5.04.2-1 > > > > I guess I need to update libc and libreadline. Can anyone > point me at the > > rpms to do this? > > If you go to <URL: http://fr2.rpmfind.net > and type > libc.so.6 into the search box, it says there are 233 rpms > that provide it. You can constrain the search to the > distribution you are using, which would narrow things down a > bit. Upgrading libc is not something I'd recommend. Instead, get the right RPM for your distribution: we have separate RPMs for RedHat 8.0 and 7.2 these days (using the wrong one leads to strange problems). The 8.0 RPM is rumoured to work with 7.3. I'm afraid we don't do a great job of supporting non-RedHat Linux systems at the moment, except for Debian which I believe does its own packaging of GHC. We do have a .tar.bz2 "binary distribution" which *might* work for you, but it is also reliant on you having the right libraries installed. Cheers, Simon

2 1

5.04.2 RPM Dependencies
by Dominic Steinitz 11 Mar '03

11 Mar '03

Can anyone help? I downloaded the latest rpm for ghc but got the following errors on installation: error: failed dependencies: libc.so.6(GLIBC_2.3) is needed by ghc-5.04.2-1 libreadline.so.4 is needed by ghc-5.04.2-1 I guess I need to update libc and libreadline. Can anyone point me at the rpms to do this? By the way I didn't have this problem with 5.04.1. Dominic Steinitz

2 1

Type classes problem: Could not deduce ...
by dirk.buehler＠student.uni-tuebingen.de 10 Mar '03

10 Mar '03

Hello, trying to compile the following program class ClassA a where foo :: a -> Int class ClassA a => ClassB b a where toA :: b -> a test :: (ClassB b a) => b -> Int test x = let y = toA x in let z = foo y in z I get a compilation error: TestTypeClasses.hs:12: Could not deduce (ClassB b a1) from the context (ClassB b a) Probable fix: Add (ClassB b a1) to the type signature(s) for `test' arising from use of `toA' at TestTypeClasses.hs:12 In a pattern binding: toA x Can anybody explain the problem to me or suggest workarounds? Adding (ClassB b a1) to the context does not solve the problem, it just generates an error of the same sort. Any hints are appreciated. Cheers, dirk ______________________________________________________________________________ Werden Sie kreativ! Bei WEB.DE FreeMail heisst es jetzt nicht nur schreiben, sondern auch gestalten. http://freemail.web.de/features/?mc=021142

2 1

RE: Effect of large binaries on garbage collection
by Simon Marlow 10 Mar '03

10 Mar '03

> > Thanks, looks like it's option (1) then. Could you tell me what > > Haskell type I have to use be able to pass a pointer to this binary > > to C land (genuine address, not StablePtr). I don't think > > the standard FFI allows this at all but, IIRC, the old ghc libraries > > allowed you to do this with a mutable byte array. > > Does anybody know the answer to this? please.. pretty please..:-) > > Sorry if this is a case of me failing to RTFM, but I don't > think it is. Paragraph 8.1.1 of the users guide says.. > > "The types ByteArray and MutableByteArray may be used as basic > foreign types (see FFI Addendum, Section 3.2). In C land, > they map to (char *)." This is still true for 5.04.x: the ByteArray and MutableArray libs in hslibs (package lang) provide these types, but they are deprecated and will be removed at some point. The functionality which allows ByteArray and MutableByteArrays to be passed to FFI functions has already been removed in CVS. In the current CVS GHC, undoubtedly the right thing to use is Foreign.mallocForeignPtr. Internally these are implemented as MutableByteArray#, so you get fast allocation and GC, but from the programmer's point of view it's a normal ForeignPtr. If you don't mind the not-so-great performance, you can use ForeignPtr with malloc/free in 5.04.x and convert to mallocForeignPtr when the next major release of GHC comes along. Or you can use ByteArray/MutableByteArray for the time being (note that you can only pass one of these to an "unsafe" FFI function, BTW). Cheers, Simon

1 0

RE: Effect of large binaries on garbage collection
by Simon Peyton-Jones 10 Mar '03

10 Mar '03

GHC does not copy big objects, so don't worry about the copying cost. (Instead of copying, it allocates big objects to (a contiguous series of) heap blocks, with no other objects in those blocks. Then the object can "move" simply by swizzling the heap-block descriptor.) Simon | -----Original Message----- | From: Adrian Hey [mailto:ahey@iee.org] | Sent: 04 March 2003 11:05 | To: glasgow-haskell-users(a)haskell.org | Subject: Effect of large binaries on garbage collection | | Hello, | | I'm writing a library which will require many blocks of binary data | of various sizes (some very large) to be stored in the heap. I'm a | little worried about the effect this will have on the efficiency of | garbage collection. I'm not sure how ghc gc works these days, but | I seem to remember it's a copying collector by default. If so it seems | a pity to waste time copying 10's of MBytes of binaries at each | collection. | | The options I'm considering are.. | | (1) Use Haskell heap space | Pros: Easy for me | Cons: May slow down gc | AFAICS I can't use anything like realloc | Current FFI proposals seem to prevent me from directly | accessing Haskell heap objects from C land (or have I | misunderstood?). | | (2) Use C heap space | Pros: Easy(ish) to use from C and Haskell ffi | Cons: Unless C heaps have improved a lot since I last looked | (which I doubt), it seems likely I will suffer from slow | allocation and fragmentation problems. | | (3) Write my own "sliding" heap manager and use finalisers for | garbage collection. | Pros: Can tailor it to work exactly the way I want. | Cons: More work for me, especially if I want the | result to be portable across OS's. | Might be a complete waste of time if my worries | about ghc heap management are groundless :-) | | Any advice? | | Thanks | -- | Adrian Hey | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 2

fun with sockets (ghc-5.04.1)
by Peter Thiemann 09 Mar '03

09 Mar '03

Hi, I'm running into a problem using server code (running on a UNIX domain socket) that I basically snatched from Simon Marlow's web server: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ mainLoop sock defUser getMs = do putStrLn "Accepting connections..." installHandler sigPIPE Ignore Nothing loop (0::Int) where loop n = do (connection, peerAddress) <- accept sock h <- socketToHandle connection ReadWriteMode forkIO ( (talk n getMs defUser h `finally` goodBye n h) `Exception.catch` (\e -> putStrLn ("Exception: " ++ show e)) ) loop (n+1) goodBye n h = do putStrLn (show n ++ ": finished") hClose h ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ After processing a random number of connections, the server dies with Fail: invalid argument Action: accept Reason: Invalid argument after finishing the last connection. For the record, here is the code that is executed for each connection: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ talk n getMs user h = do hSetBuffering h LineBuffering putStrLn (show n ++ ": ") str <- hGetLine h lstr <- hGetLine h putStrLn ("...: " ++ lstr) -- last output before core dump let msglength = read (takeWhile isDigit (drop 1 lstr)) rawmsg <- hGetContents h putStrLn ("Got " ++ show (length msg) ++ " characters") ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The machine is Linux kailua 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 unknown The problem seems to go away if I switch to INET sockets, so I'm also including my initialization code: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ withSocketsDo $ do sock <- socket AF_UNIX Stream 0 bindSocket sock (SockAddrUnix path) listen sock maxListenQueue getMs <- initializeAll mainLoop sock defUser getMs ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Peter

1 0

RE: Stack profiling
by Simon Marlow 06 Mar '03

06 Mar '03

> > In the CVS version there's a -xt RTS flag that enables inclusion of > > thread stacks in a heap profile. It's crude, because thread stacks > > grow > > by doubling their size every time they run out of space, > but it should > > be enough to show the difference between O(n) stack usage and O(1). > > Hmm. That sounds like what I need, I think. Is it in HEAD or in the > 5.04 (now 5.04.3?) branch? It's only in the HEAD. Cheers, Simon

1 0

RE: Stack profiling
by Simon Marlow 06 Mar '03

06 Mar '03

> | > Stephen Pitts <smpitts(a)ou.edu> wrote: > | >> Is there an easy way to profile stack usage without > rebuilding with > | >> ticky-ticky profiling? I have two implementations of an > algorithm; > | >> the one with straight lists seems to use constant stack, > while the > | >> one with a JoinList is eating up stack at an O(n) rate. > > I don't think there is right now. What sort of profile would you like > to see in an ideal world? What sort of profile would still be useful, > even if not ideal? Remember that GHC is a concurrent system, so there > may be many threads running, each with its own stack. > > Even with ticky-ticky, I'm not sure if we capture maximum > stack depth at > the moment. But I agree that something along those lines > sounds useful. > > Anyone feel like helping implement it, if we could agree a spec? In the CVS version there's a -xt RTS flag that enables inclusion of thread stacks in a heap profile. It's crude, because thread stacks grow by doubling their size every time they run out of space, but it should be enough to show the difference between O(n) stack usage and O(1). Cheers, Simon

2 1

How Make a executable file in Glasgow
by jmario＠uniquindio.edu.co 06 Mar '03

06 Mar '03

Hello, i am beginner in Glasgow and Haskell, And I would like to know How I do to create a executable file in Glasgow (*.exe) thanks! Mario

2 1

GHC's readLitChar does not conform to 98
by Akim Demaille 05 Mar '03

05 Mar '03

Hi! I believe the implementation of readLitChar (and lexLitChar) does not conform to the documentation, and this results in GHC and Hugs disagreeing on the following code: ---------------------------------------- module Main (main) where import IO (stderr, hPutStrLn) import Char (digitToInt, lexLitChar, readLitChar) main :: IO () main = do hPutStrLn stderr (show $ readLitChar "A") hPutStrLn stderr (show $ readLitChar "'A'") ---------------------------------------- ghc says: /tmp % ghc --version nostromo 14:45 The Glorious Glasgow Haskell Compilation System, version 5.04.2 /tmp % /tmp/a.out nostromo 14:46 [] [('A',"")] and Hugs says: /tmp % runhugs Main.hs nostromo Err 1 [('A',"")] [('\'',"A'")] The doc seems to agree with Hugs (thanks to sebc for the pointer): <http://www.haskell.org/onlinereport/char.html> > The function showLitChar converts a character to a string using only > printable characters, using Haskell source-language escape > conventions. The function lexLitChar does the reverse, returning the > sequence of characters that encode the character. The function > readLitChar does the same, but in addition converts the to the > character that it encodes. For example: > > showLitChar '\n' s = "\\n" ++ s > lexLitChar "\\nHello" = [("\\n", "Hello")] > readLitChar "\\nHello" = [('\n', "Hello")]

1 0