- Glasgow-haskell-users

How do I force evaluation?
by fis＠ssh.com 12 Mar '01

12 Mar '01

Hi, I want to do something like: | main = do | monstrousDataStructure <- monstrousComputation | hPutStr stderr "success!" | ... The important point is that I want to make sure that the computation has terminated and not failed before I go to `...'. I have tried | x <- x `seq` x and | x <- id $! x which should be equivalent anyway, but they both did not have any effect. Then, I remember that there was something called strict, but I can't find it any more. I am afraid I am missing something basic here. If you can't help me, I will come back with a more precise example, I just haven't found one so far (only the original code, but you don't want to read 1843 LOC on this list, do you?... :) thanks a lot, Matthias -- Matthias Fischmann | Research Engineer | +358 (9) 8565 7474 fis(a)ssh.fi | SSH Communication Security Corp | +358 (40) 752 5291

2 1

Re: trouble with ghc-4.08.2-1.i386.rpm
by Jens-Ulrik Petersen 09 Mar '01

09 Mar '01

"Jens-Ulrik Petersen" <jens-ulrik.petersen(a)nokia.com> writes: > I tried ghc-4.08.2-1.i386.rpm (both the RH-6 rpm and the RH-7 rpm) on > my Linux box running RH rawhide-2001-02-06 (a touch newer than the > RH-7.0.90 beta release Fisher), which both use glibc-2.2.1. > > When I compile a program, eg a test program like "test.hs": [:] > I get [..] linking errors: [:] > I think these are related to gmp2. Oops, I just realised that I has gmp-devel-3 installed, which was causing my linking problem. Installing gmp-devel-2 and everything is as it should be. > (BTW are there plans to upgrade to gmp3, which seems to be standard > now in the Linux world?) Any comments on this? Thanks, Jens

2 1

trouble with ghc-4.08.2-1.i386.rpm
by Jens-Ulrik Petersen 09 Mar '01

09 Mar '01

I tried ghc-4.08.2-1.i386.rpm (both the RH-6 rpm and the RH-7 rpm) on my Linux box running RH rawhide-2001-02-06 (a touch newer than the RH-7.0.90 beta release Fisher), which both use glibc-2.2.1. When I compile a program, eg a test program like "test.hs": module Main (main) where main = putStrLn "Hello!" I get a put linking errors: ---- Start of included text -----------------------8<--- cut here ------------- % ghc test.hs /usr/lib/ghc-4.08.2/libHSrts.a(Storage.o): In function `initStorage': Storage.o(.text+0x2c2): undefined reference to `mp_set_memory_functions' /usr/lib/ghc-4.08.2/libHSrts.a(PrimOps.o): In function `addr2Integerzh_fast': PrimOps.o(.text+0x4a6): undefined reference to `mpz_init_set_str' /usr/lib/ghc-4.08.2/libHSrts.a(PrimOps.o): In function `plusIntegerzh_fast': PrimOps.o(.text+0x6fa): undefined reference to `mpz_init' PrimOps.o(.text+0x710): undefined reference to `mpz_add' /usr/lib/ghc-4.08.2/libHSrts.a(PrimOps.o): In function `minusIntegerzh_fast': PrimOps.o(.text+0x78e): undefined reference to `mpz_init' PrimOps.o(.text+0x7a4): undefined reference to `mpz_sub' /usr/lib/ghc-4.08.2/libHSrts.a(PrimOps.o): In function `timesIntegerzh_fast': PrimOps.o(.text+0x822): undefined reference to `mpz_init' PrimOps.o(.text+0x838): undefined reference to `mpz_mul' /usr/lib/ghc-4.08.2/libHSrts.a(PrimOps.o): In function `gcdIntegerzh_fast': PrimOps.o(.text+0x8b6): undefined reference to `mpz_init' PrimOps.o(.text+0x8cc): undefined reference to `mpz_gcd' /usr/lib/ghc-4.08.2/libHSrts.a(PrimOps.o): In function `quotIntegerzh_fast': PrimOps.o(.text+0x94a): undefined reference to `mpz_init' PrimOps.o(.text+0x960): undefined reference to `mpz_tdiv_q' /usr/lib/ghc-4.08.2/libHSrts.a(PrimOps.o): In function `remIntegerzh_fast': PrimOps.o(.text+0x9de): undefined reference to `mpz_init' PrimOps.o(.text+0x9f4): undefined reference to `mpz_tdiv_r' /usr/lib/ghc-4.08.2/libHSrts.a(PrimOps.o): In function `divExactIntegerzh_fast': PrimOps.o(.text+0xa72): undefined reference to `mpz_init' PrimOps.o(.text+0xa88): undefined reference to `mpz_divexact' /usr/lib/ghc-4.08.2/libHSrts.a(PrimOps.o): In function `quotRemIntegerzh_fast': PrimOps.o(.text+0xb06): undefined reference to `mpz_init' PrimOps.o(.text+0xb15): undefined reference to `mpz_init' PrimOps.o(.text+0xb2f): undefined reference to `mpz_tdiv_qr' /usr/lib/ghc-4.08.2/libHSrts.a(PrimOps.o): In function `divModIntegerzh_fast': PrimOps.o(.text+0xbbe): undefined reference to `mpz_init' PrimOps.o(.text+0xbcd): undefined reference to `mpz_init' PrimOps.o(.text+0xbe7): undefined reference to `mpz_fdiv_qr' collect2: ld returned 1 exit status ---- End of included text -------------------------8<--- and here ------------- I think these are related to gmp2. (BTW are there plans to upgrade to gmp3, which seems to be standard now in the Linux world?) I can compile ok with nhc98 (from "nhc98-1.02-1.i386.rpm"). Any ideas why the ghc rpms aren't working for me? Best wishes, Jens

1 0

RE: Fail: thread killed
by Simon Marlow 08 Mar '01

08 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. Ok, so which exceptions should be displayed? - Marcin says all async exceptions should be suppressed in child threads. - George says BlockedOnDeadMVar messages should also be suppressed (presumably only on child threads). any others? I'm not sure I agree that StackOverflow/HeapOverflow messages should be suppressed. It might be really confusing if your program just deadlocks instead of completing, when what actually happened was one of the child threads got a stack overflow and died silently. I can see the point about ThreadKilled though. There's only one way to kill a thread, and that's with killThread, so you don't want to see a message saying the thread was killed (except that the presence of the message indicates that the thread was alive before it was killed ;-). Cheers, Simon

1 0

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