March 2001 - Glasgow-haskell-users

RE: AIX port
by Simon Marlow 19 Mar '01

19 Mar '01

> I've got access to an IBM RS/6000SP system, with the > Power3 CPUs. I'd love to see GHC up and running on > this system. According to the list of working ports, > this wouldn't be too hard to get working. > > Has anyone tried doing this? Are there any tips > for how to begin? No one has tried recently, as far as I know. A good place to start would be to read the recent discussions on this list regarding porting to PowerPC/MacOS-X. The basic idea is to get the system up and running "unregisterised" first, which can be done with just a C compiler on the host system, then try to get the registerised bits working. The MacOS X port is still at the unregisterised stage, but they have a problem with a seriously crippled gcc. Asuming AIX's gcc is ok, it's just a case of updating a few bits & pieces, and possibly pulling in some small bits of code from the GHC 3.X runtime. We'll be happy to help out along the way. Cheers, Simon

1 0

AIX port
by Brian Gregor 18 Mar '01

18 Mar '01

I've got access to an IBM RS/6000SP system, with the Power3 CPUs. I'd love to see GHC up and running on this system. According to the list of working ports, this wouldn't be too hard to get working. Has anyone tried doing this? Are there any tips for how to begin? -brian

1 0

Re: How do I force evaluation?
by Matthias Fischmann 13 Mar '01

13 Mar '01

Yes, that does not look very nice but it should work. In a private response, I was also pointed out the alternative solution of using case together with `seq` to trigger evaluation, which looked like the default way to me (what else is seq for?): | case monstrousDS `seq` True of True -> hPutStr stderr "ok." I first tried to wrap this in a `force' function, thereby proving that I still haven't grasped the concept entirely. (-: But maybe it is possible to make a primitive of this in the same way as has been done with assert? Anyway thanks for all your help, Matthias "Jan de Wit" <jwit(a)studenten.net> writes: > 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 `...'. > If the monstrous data structure has a 'serious' equality (not always > returning True), you can try: > > | main = do > | monstrousDataStructure <- monstrousComputation > | if (monstrousDataStructure == monstrousDataStructure) then > | hPutStr stderr "success!" > | else > | hPutStr stderr "failure?" > > The idea is that comparing for equality walks over the entire data > structure, forcing evaluation because every location has to be inspected. > > Hope this helps, > Jan de Wit > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Matthias Fischmann | Research Engineer | +358 (9) 8565 7474 fis(a)ssh.fi | SSH Communication Security Corp | +358 (40) 752 5291

2 1

GHC HQ are looking for a Linux-IA64 box
by Julian Seward (Intl Vendor) 12 Mar '01

12 Mar '01

[Apologies if you get multiple copies of this msg.] Folks, Following a recent discussion about future development directions for GHC, it seems one thing we want to start thinking about is support for the IA64 architecture. Does any kind person have an IA64 box, running Linux, on which we could have an account? The extent of the work would be to make GHC's runtime-support system work again on a 64-bit platform (it used to), and possibly to build an IA64 native code generator. This work would be spread across a couple of months, I imagine. Basic requirements are: * IA64 Linux box, with development tools (gcc, perl, autoconf, gdb, etc -- all the usual Linux/Unix stuff). * As many spare processor cycles as possible. GHC building/debugging tends to CPU intensive. Also, probably at least 256MB of memory would be necessary to keep us out of trouble. * At a bare minimum, 300 MB of free disk space; 1 GB would be preferable, since it would allow more thorough testing of the system. * Decent, permanent, reliable internet connection from so that we can work remotely (obviously) and so that we can talk to our CVS server. I'd say at a bare minimum a 128 kb/sec connection. Preferably as few as possible network hops from Cambridge, UK. This work is likely to be on-and-off (not all the time) over a couple of months, I'd guess. We probably won't be ready to start on it for at least a month, so some time around the start of May would be when we'd really want to start moving on this. Availability of such a machine would be a useful contribution to the GHC development effort, so we'd be grateful if any of you could point us in the right direction. J (speaking for the GHC crew as a whole)

2 1

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