December 2005 - Haskell-Cafe

[Newbie] Why or why not haskell ?
by Christophe Plasschaert 12 Dec '05

12 Dec '05

First, i'd like to say good day to everybody. I didn't find enough information to anwser this question: Being interesting in learning another way of programming besides C and perl i started watching other languages. These are my candidates: - ada; - erlang; - clisp or scheme; and of course - haskell. Haskell seems very interesting indeed (monadic, STM, a good library). Maybe some of you know some or all of these languages and can explain me some pros/cons about them especially for network programming. Thanks for your attention. Have a nice day. C. Plasschaert

10 16

Re: [Haskell-cafe] Opening the same file multiple times
by Donn Cave 12 Dec '05

12 Dec '05

Quoth Einar Karttunen <ekarttun(a)cs.helsinki.fi>: | On 11.12 22:26, Donn Cave wrote: | > Quoth Einar Karttunen <ekarttun(a)cs.helsinki.fi>: | > | It seems that opening the same file multiple times (one writer | > | and multiple readers) is not supported at least on *nix with | > | GHC. I want to use one Handle to use append data till the | > | end of the file while other Handles perform random access | > | IO with seeks on the file. | > | > How is it not supported? What happens with something like this ... | *** Exception: z: openFile: resource busy (file is locked) Oh. Well, that's unfortunate, but at least I see it is documented. I guess that explains why your solution uses unlockFile. I suppose you might be able to use Posix.IO functions instead, but that would probably be even more trouble than your work-around. Donn Cave, donn(a)drizzle.com

2 3

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

12 Dec '05

On 12 December 2005 17:53, Donn Cave wrote: > Quoth Einar Karttunen <ekarttun(a)cs.helsinki.fi>: > ... >> *** Exception: z: openFile: resource busy (file is locked) > > Now that I have access to a platform where ghc builds, I can > duplicate your results - and in case it helps, here's another > work-around. Apparently this "feature" uses POSIX filesystem > locks, because it appears that we can exploit the brain-damaged > semantics of that system: when a process closes a file, all > its locks are cleared - whether they were acquired through that > file descriptor or another unrelated open. It may be the first > time anyone has ever benefited from this! > > import IO > > main = do > fc <- openFile "z" ReadMode -- sacrificial handle > fr <- openFile "z" ReadMode > hClose fc > fa <- openFile "z" AppendMode > hPutStr fa "append this line\n" > hGetLine fr >>= print > > If you may need to open more read handles later, you can add > another extra close after the append handle. Thank you (I suppose :-) for exposing a bug in GHC's file locking. It doesn't have anything to do with POSIX filesystem locks, FWIW, it's just a bug, in some very old code. Cheers, Simon

1 0

syscall, sigpause and EINTR on Mac OSX
by Joel Reymont 12 Dec '05

12 Dec '05

Folks, I'm kind of stuck on this and can't figure it out... Take a look at the trace below, this is Mac OSX Tiger. (gdb) where #0 0x90006068 in syscall () #1 0x9004420c in sigpause () #2 0x001791b8 in awaitUserSignals () at Signals.c:256 #3 0x0012e1a8 in schedule (mainThread=0x1300360, initialCapability=0x0) at Schedule.c:518 #4 0x0012f340 in waitThread_ (m=0x1300360, initialCapability=0x0) at Schedule.c:2156 #5 0x0012f224 in scheduleWaitThread (tso=0x15c0000, ret=0x0, initialCapability=0x0) at Schedule.c:2050 #6 0x0012ba18 in rts_evalLazyIO (p=0x215254, ret=0x0) at RtsAPI.c:459 #7 0x0001ea7c in main (argc=4, argv=0x0) at Main.c:104 (gdb) p16 $r22 0x40: Cannot access memory at address 0x40 My program is currently stuck here. The man pages say that sigpause will only terminate by being interrupted and EINTR will be the errno. EINTR is signal 2, the same one that I'm trapping and the one sent when ^C is pressed. This probably explains why my signal handler is getting hit from time to time without any input from me. My program then exits and leaves me very puzzled as the whole thing looks like someone sneaked up to my keyboard and hit ^C to interrupt the program. I'm not making any sense of this. Why would someone be calling sigpause and making it interrupt my program? How can I work around this? I guess I'll poke around the ghc internals a bit and see what's cooking. Thanks, Joel -- http://wagerlabs.com/

6 37

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