- Glasgow-haskell-users

Re: Fail: thread killed
by George Russell 07 Mar '01

07 Mar '01

Marcin 'Qrczak' Kowalczyk wrote: [snip] > Since the very purpose of killThread is to kill the damn thread, > I find it inconvenient to have to wrap any thread which is supposed > to be killable with Exception.catch to avoid the message. Worse: > it should use block and unblock, otherwise there is a small window > where killing the thread will still display the message. [snip] I agree with this. I also find it mildly irritating having to catch exceptions to stop GHC informing me that it's just garbage collected a thread which is permanently deadlocked.

1 0

Fail: thread killed
by qrczak＠knm.org.pl 06 Mar '01

06 Mar '01

I think I have raised the issue some time ago, but don't remember why it hasn't been solved as I would like to. Currently a thread which is killed displays Fail: thread killed, e.g. in the following program: import Concurrent main:: IO () main = do t <- forkIO (threadDelay 1000000) threadDelay 500000 killThread t threadDelay 500000 Since the very purpose of killThread is to kill the damn thread, I find it inconvenient to have to wrap any thread which is supposed to be killable with Exception.catch to avoid the message. Worse: it should use block and unblock, otherwise there is a small window where killing the thread will still display the message. I can probably agree that other kinds of exceptions are displayed; maybe the programmer didn't know that exceptions are being thrown and wants the diagnostic. It implies that any well-written code should catch exceptions in all threads it creates (unless he is sure that the code will not throw exceptions), since there shouldn't be compiler's error output from a correct program. Not nice but I can live with that. Should asynchronous exceptions be really displayed in threads other than the main thread? IMHO not. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: Bagley shootout. Was: Lightningspeed haskell
by Simon Marlow 06 Mar '01

06 Mar '01

> Reducing the 46M reported on the shootout without changing the > program would be interesting. An easy way for improvement > would be to share characters and small integers like is done in Hugs. > This would mean the initial list of characters would be reduced from > 40M to 24M, so the total should go down from 46M to 30M. We do share characters and small integers. Cheers, Simon

2 1

PrimIO
by Simon Marlow 02 Mar '01

02 Mar '01

Quick poll: Is anyone still using the PrimIO type and combinators from GlaExts? It's high time we removed them. In fact, there's nothing in this module that isn't either deprecated or can be got from somewhere else. I think GlaExts will be deprecated in the next release. Cheers, Simon

2 1

runProcess/ createPipe
by George Russell 02 Mar '01

02 Mar '01

If Posix.runProcess really is supposed "our candidate for the high-level OS-independent primitive" (see documentation), it would help if there was a documented way of using it with pipes. The problem is that runProcess takes handles as arguments, while the obvious function, createPipe, returns two Fds. There seems to be no _documented_ way of converting an Fd to a Handle. I suggest therefore that either there be a createPipeHandle :: IO (Handle,Handle) (which would be nice, because it might avoid bothering the operating system completely, and would makes sense on non-Posix systems). Or else, the existing Posix.fdToHandle fdToHandle :: Fd -> IO Handle should be documented.

1 0

RE: Bagley shootout. Was: Lightningspeed haskell
by Simon Peyton-Jones 02 Mar '01

02 Mar '01

A String is a [Char] and a Char is a heap object. So a file represented as a string takes a massive 20 bytes/char (12 for the cons cell, 8 for the Char cell). Then it's all sucked through several functions. It's entirely possible, though, that the biggest performance hit is in the I/O itself. We'd be happy if anyone wanted to invesigate and improve. Simon | -----Original Message----- | From: John Atwood [mailto:atwoodj@cs.orst.edu] | Sent: 02 March 2001 01:12 | To: Josef Svenningsson | Cc: glasgow-haskell-users(a)haskell.org | Subject: Bagley shootout. Was: Lightningspeed haskell | | | I notice that the reverse file program, while concise, is quite slow. | The program in its entirety is: | main = interact $ unlines . reverse . lines | | Any thoughts on why its time is 5.68 seconds, vs 3.56 for tcl, 2 for | perl, 0.19 for gcc, 0.18 for ocaml; and how it might be sped | up? Is the | lack of speed all in the stdio I/O? | | Is there a way to tell which benchmarks have no haskell entry? | | John Atwood | -- | | Josef Svenningsson wrote: | > | > Hi all. | > | > Some days ago someone posted this url: | > http://www.bagley.org/~doug/shootout/ | > | > which is a page benchmarking a number of different languages and | > compilers where ghc is one of them. Some benchmarks lacked a haskell | > versions (and some still do) and so I decided to fill in | some of the gaps. | > | > One benchmark turned out to give pretty remarkable results. It's the | > producer/consumer benchmark. I suggest you all take a look | at it. The | > haskell version is six (SIX!!!) times faster than the c | version. Hey, | > what's going on here? I would really like to hear some | comments from our | > dear implementors. | > | > It should be noted that synchronisation is achieved by using | > slightly different kinds of primitives. But still... six times... | > | > I lift my hat of for the ghc-implementors. | > | > /Josef | > | > | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users(a)haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

3 3

RE: Concurrency in GHCi
by Simon Marlow 02 Mar '01

02 Mar '01

> The little program below is to test an idea to try to interact > using Hugs or GHCi with a running program. > > To use the program: > 1. Start the server with "addServer addChan" > 2. Write requests to addChan "writeChan addChan (Add 3 4)" > > The program seems to work OK in Hugs, but crashes out with > "ghc: no threads to run". > > Can anybody suggest a way of getting this to run properly with > GHCi? I think you wanted "forkIO (addServer addChan)", because addServer immediately attempts to read from the channel and will block if there's no data available. Oh, and you should really say "{-# NOINLINE addChan #-}" to prevent it being accidentally duplicated. Cheers, Simon

1 0

Lightningspeed haskell
by Josef Svenningsson 02 Mar '01

02 Mar '01

Hi all. Some days ago someone posted this url: http://www.bagley.org/~doug/shootout/ which is a page benchmarking a number of different languages and compilers where ghc is one of them. Some benchmarks lacked a haskell versions (and some still do) and so I decided to fill in some of the gaps. One benchmark turned out to give pretty remarkable results. It's the producer/consumer benchmark. I suggest you all take a look at it. The haskell version is six (SIX!!!) times faster than the c version. Hey, what's going on here? I would really like to hear some comments from our dear implementors. It should be noted that synchronisation is achieved by using slightly different kinds of primitives. But still... six times... I lift my hat of for the ghc-implementors. /Josef

2 1

Concurrency in GHCi
by John Knottenbelt 01 Mar '01

01 Mar '01

Hi The little program below is to test an idea to try to interact using Hugs or GHCi with a running program. To use the program: 1. Start the server with "addServer addChan" 2. Write requests to addChan "writeChan addChan (Add 3 4)" The program seems to work OK in Hugs, but crashes out with "ghc: no threads to run". Can anybody suggest a way of getting this to run properly with GHCi? Thanks Johnny ---- Transcript of a Hugs session: Type :? for help ConcTest> addServer addChan addServer started ConcTest> writeChan addChan (Add 3 4) 1: addServer: 3 + 4 = 7 ---- Transcript of a GHCi session: Loading package concurrent ... linking ... done. Compiling ConcTest ... compilation IS required ConcTest> addServer addChan addServer started ghc: no threads to run: infinite loop or deadlock? bash$ ---- module ConcTest where import Concurrent import IOExts data AddMsg = Add Int Int | Quit addServer :: Chan AddMsg -> IO () addServer c = do putStrLn "addServer started" loop 1 putStrLn "addServer finished" where loop msgNum = do msg <- readChan c case msg of Add x y -> do putStrLn (show msgNum ++ ": addServer: " ++ show x ++ " + " ++ show y ++ " = " ++ show (x + y)) loop (msgNum + 1) Quit -> return () addChan :: Chan AddMsg addChan = unsafePerformIO newChan

1 0

Re: New InstallShield
by Sigbjorn Finne 01 Mar '01

01 Mar '01

Reuben Thomas rrt1001(a)cam.ac.uk writes: > > > I didn't know the windows port of GHC used mingwin, that is great news. > > Does that mean it is possible to generate stand alone applications for > > Windows ? > > Yes; it always has been! ghc-4.04 (or was it 4.03?) added support for compiling via mingw, before that all exes had to depend on cygwin.dll > > Would it be hard to configure GHC to work with the mingwin crosscompiler > > on Linux ? It would be great to have a crosscompiling GHC. > > Not a clue. I'd be delighted to hear about this. I suspect the build system > would need ironing out somewhat, but in theory > > ./configure --target=i386-unknown-mingw32 > > ought to do something sensible. Unless someone's bitten the bullet on this one recently, the mk/ setup doesn't deal with cross-compilation at all (nor does the driver); indeed I believe the configure script will even prevent you from trying. --sigbjorn

1 0