- Haskell-Cafe - Haskell.org

Differences in optimisiation with interactive and compiled mode
by Branimir Maksimovic 12 Dec '05

12 Dec '05

It seems that compiled programs run better then interactive ones. Following program with GHC works with pretty good performance in comparison to C++ one with similar but non recursive algorithm and beats it in memory consumtion. It only takes about 2mb of ram somehow when running compiled. I'm really amased. But in interactive mode both GHC and Hugs fail due heap exhaustion and running takes ages.Please can someone explain why? I intent to use only compiled Haskell anyway so GHC satisfies. Greetings, Bane. program performs search replace on a String module Main where import IO main = do hSetBuffering stdout LineBuffering let sr = "search" rp = "replace" str= " able search sea baker search charlie \"" out = searchr sr rp (take (1000000*(length str)) $ infinite str) out1 = searchr sr rp (take (1000001*(length str)) $ infinite str) putStrLn $ "Working:" ++ sr ++ " " ++ rp ++ " " ++ str putStrLn $ (show (out == out1)) ++ "\n" ++ "\nDone\n" {- search replace " able search baker search charlie " -} ------------------------------------------------------------------------------- infinite xs = xs ++ infinite xs searchr :: String->String->String -> String searchr [] _ xs = xs searchr _ [] xs = xs searchr _ _ [] = [] searchr sr rp xs | fst fnd = rp ++ searchr sr rp (snd $ snd fnd) | otherwise = (reverse $ fst $ snd fnd) ++ searchr sr rp (snd $ snd fnd) where fnd = searchr' sr xs "" searchr' :: String->String->String -> (Bool,(String,String)) searchr' (sr:srs) xs fndSoFar = searchr'' (sr:srs) xs fndSoFar sr searchr'' :: String->String->String->Char -> (Bool,(String,String)) searchr'' [] xs fnd _ = (True,(fnd,xs)) searchr'' _ [] fnd _ = (False,(fnd,[])) searchr'' (sr:srs) (x:xs) fndSoFar s | sr == x = searchr'' srs xs xxs s | otherwise = (False,searchr''' s xs xxs) -- (False,(xxs,xs)) where xxs = x:fndSoFar searchr''' :: Char->String->String -> (String,String) searchr''' sr [] fndSoFar = (fndSoFar,[]) searchr''' sr (x:xs) fndSoFar | sr /= x = searchr''' sr xs (x:fndSoFar) | otherwise = (fndSoFar,x:xs) ------------------------------------------------------------------------------- _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

8 41

RE: [Haskell-cafe] STM, orElse and timed read from a channel
by Simon Marlow 12 Dec '05

12 Dec '05

On 12 December 2005 10:09, Joel Reymont wrote: > While we are waiting for ghc 6.6, could the same effect be achieved > by launching the computation that writes to t with forkIO? Certainly. registerTimeout is just an optimisation that avoids creating a new thread each time. Cheers, Simon > On Nov 29, 2005, at 12:00 PM, Simon Marlow wrote: > >> threadDelay is IO-only; there's no way to use threadDelay in an STM >> transaction. For example, if you want to wait for a TVar to go from >> Nothing to Just x with a timeout, you could do this: >> >> readOrTimeout :: TVar (Maybe a) -> Int -> STM (Maybe a) >> readOrTimeout t secs = do timeout <- registerTimeout secs >> let check_timeout = do >> b <- readTVar timeout >> if b then return Nothing else retry >> check_t = do >> m <- readTVar t >> case m of >> Nothing -> retry >> Just x -> return x >> atomically $ check_timeout `orElse` check_t

1 0

RE: [Haskell-cafe] Opening the same file multiple times
by Simon Marlow 12 Dec '05

12 Dec '05

On 12 December 2005 14:01, Einar Karttunen wrote: > On 12.12 12:06, Duncan Coutts wrote: >> It states in the Haskell Report 21.2.3: >> >> http://haskell.org/onlinereport/io.html > > Thanks, for the pointer, but am looking for an extension > in the non-haskell98 API to do it. > > It seems that things are quite problematic: > > 1) Use openFile or GHC.Handle.openFd > > Works in Hugs, fails as the standard mandates in GHC > due to locking. This is fine. You can trick openFd into not locking the file by passing (Just RawDevice) as the file type. Ugly, but should work. Cheers, Simon

1 0

RE: [Haskell-cafe] Re: syscall, sigpause and EINTR on Mac OSX
by Simon Marlow 12 Dec '05

12 Dec '05

On 11 December 2005 17:19, Joel Reymont wrote: > Nothing like answering your own questions... > > There's no deadlock information for the threaded version of the > runtime so I would not have deadlock information if I were to compile > with -threaded. This doesn't really help you right now, but -threaded has better deadlock detection in GHC 6.6. Cheers, Simon

1 0

RE: [Haskell] fptools mirror in darcs ready for testing
by Simon Marlow 12 Dec '05

12 Dec '05

On 08 December 2005 18:21, Malcolm Wallace wrote: >> http://cvs.haskell.org/darcs/ghc >> http://cvs.haskell.org/darcs/libraries > > It suddenly occurs to me that there are other projects in CVS > that have not yet been converted to darcs, e.g. Hugs98 and nhc98. > Are there plans to do so? If not, then since both of these depend > on the libraries tree, there will need to be some other plan to cope > with the eventual dropping of the libraries CVS archive. > > There are also a bunch of other smaller, more stand-alone projects > like cpphs, hat, ohugs, programmatica, timber. The long-term plan > for Hat is to depend on the libraries tree, although it does not do > so currently. Hugs98 and nhc98 both currently depend on cpphs. It might be worthwhile someone setting up a mirror from darcs->CVS to keep the libraries CVS tree up to date, to help support these other projects that aren't moving to darcs yet (or at all?). John Goerzen has told me that setting up a reverse mirror should be possible, but not at all trivial - and I think he's already done his fair share for the community by setting up the darcs mirror for fptools :-) So we're looking for a volunteer... Cheers, Simon

2 1

RE: [Haskell-cafe] GHCi and threads, was Connecting to a running process (REPL)
by Simon Marlow 12 Dec '05

12 Dec '05

On 10 December 2005 23:45, Rohan Drape wrote: > On Tue Dec 6 15:01:45 EST 2005 Tomasz Zielonka wrote: > >> Unfortunately it seems that forkIO'ed threads are freezed when GHCi >> is waiting for command-line input. I bet it would be possible to let >> the threads work in the background. I think the current behaviour is >> caused by using readline, which is a foreign library. Or it is by >> design? > > I also think this is unfortunate, and would like to know if this can > be worked around (ie. I could happily live without readline if that is > the issue and it can be switched off). The fix is trivial: we have to add -threaded when we link GHCi. The only reason I haven't done this yet is because I'm being cautious; the threaded RTS is a fair bit more complex that the non-threaded RTS. I think we'll schedule this for 6.6 though. Cheers, Simon

1 0

RE: [Haskell-cafe] STM commit hooks
by Simon Marlow 12 Dec '05

12 Dec '05

On 29 November 2005 12:40, Einar Karttunen wrote: > Hello > > I have been playing with STM and want to log transactions to disk. > Defining a logging function like: > > log h act = unsafeIOToSTM $ hPrint h act > > works most the time. Aborts can be handled with: > > abort h = log h Abort >> retry > atomic' h act = atomically (act `orElse` abort h) > > But is it possible to handle a commit? > > commit h = unsafeIOToSTM (hPrint h Commit >> hSync h) > atomically2 h act = atomically ((act >> commit h) `orElse` abort h) > > This won't work because the transaction is validated and > maybe aborted after the commit is logged to disk. > > Another alternative would be: > > atomically3 h act = atomically (act `orElse` abort h) >> atomically > (commit h) If I'm understanding you correctly, what you need is to log the commit operation before another thread commits and logs a transaction. So you just need to close this race hole at the '>>' in the above definition. How about this: log_lock <- newTMVar () atomically3 h act = do atomically (do act; takeTMVar log_lock `orElse` abort h) hPrint h Commit atomically (putTMVar log_lock ()) does that work? Cheers, Simon

2 1

STM commit hooks
by Einar Karttunen 12 Dec '05

12 Dec '05

Hello I have been playing with STM and want to log transactions to disk. Defining a logging function like: log h act = unsafeIOToSTM $ hPrint h act works most the time. Aborts can be handled with: abort h = log h Abort >> retry atomic' h act = atomically (act `orElse` abort h) But is it possible to handle a commit? commit h = unsafeIOToSTM (hPrint h Commit >> hSync h) atomically2 h act = atomically ((act >> commit h) `orElse` abort h) This won't work because the transaction is validated and maybe aborted after the commit is logged to disk. Another alternative would be: atomically3 h act = atomically (act `orElse` abort h) >> atomically (commit h) But this does not work either. Given Trx1 and Trx2, the following may occur: 1) Trx1 commits <thread switch> 2) Trx2 commits (and depends on Trx1) 3) Trx2 commit is logged to disk <system crash> This means that the log would be inconsistent. Is there a way to implement the commit that works? - Einar Karttunen

2 1

RE: [Haskell-cafe] STM, orElse and timed read from a channel
by Simon Marlow 12 Dec '05

12 Dec '05

threadDelay is IO-only; there's no way to use threadDelay in an STM transaction. For example, if you want to wait for a TVar to go from Nothing to Just x with a timeout, you could do this: readOrTimeout :: TVar (Maybe a) -> Int -> STM (Maybe a) readOrTimeout t secs = do timeout <- registerTimeout secs let check_timeout = do b <- readTVar timeout if b then return Nothing else retry check_t = do m <- readTVar t case m of Nothing -> retry Just x -> return x atomically $ check_timeout `orElse` check_t Cheers, Simon On 29 November 2005 10:11, Joel Reymont wrote: > Simon, > > How is this easier than just calling threadDelay? > > Ideally, I would be looking for something like reading from a TVar > with a timeout. So that you either get a Nothing (timeout) or the > value from the TVar. Can I implement it using the GHC timeout thread? > > Thanks, Joel > > On Nov 29, 2005, at 9:20 AM, Simon Marlow wrote: > >> Interestingly, GHC already has a timeout thread - the I/O manager >> thread handles threadDelay too. It wouldn't be too hard to adapt it >> to do STM timeouts too, with a function like >> >> registerTimeout :: Int -> STM (TVar Bool) >> >> and you wait for your timeout by waiting for the TVar to contain >> True.

3 4

Existentially-quantified constructors, Eq and Show
by Joel Reymont 12 Dec '05

12 Dec '05

Folks, Is there a less verbose way of doing this: data State a = Start | Stop | (Show a, Eq a) => State a instance Eq a => Eq (State a) where (State a) == (State b) = a == b Start == Start = True Stop == Stop = True instance Show a => Show (State a) where show (State a) = show a show Start = "Start" show Stop = "Stop" Thanks, Joel -- http://wagerlabs.com/

9 18