RE: FreeBSD port of 4.06

> At Mon, 06 Mar 2000 18:43:34 +0900, > Yoshiyuki ONOUE <[EMAIL PROTECTED]> wrote: > > > See . > > Same error happened in our 3.3-RELEASE environment. > > Thank you for updating a freebsd port of ghc-4.06 and > I saw "Problem Report port

RE: GMP compilation blues.

> `/usr/local/pub-bkb/ghc/fptools/ghc/rts/gmp/mpz' > ../driver/ghc-inplace -I../includes -I. -Iparallel -optc-Wall > -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes > -optc-Wmissing-declarations -optc-Winline > -optc-Waggregate-return -optc-Wpointer-arith > -optc-Wbad-function-ca

Re: The return of the Void [Was: newtypes]

> newtype Void = Void Void deriving Show > Hugs and hbc accept it without complaining. (I haven't got nhc installed.) nhc98 reports Error when renaming:: Newtype Main.B is circular. Newtype Main.A is circular. Newtype Main.Void is circular.

GMP compilation blues.

gmake -C gmp MAKEFLAGS= cd mpn; gmake "CC=gcc" "CFLAGS=-O" "XCFLAGS=" libmpn.a gmake[4]: Entering directory `/usr/local/pub-bkb/ghc/fptools/ghc/rts/gmp/mpn' gmake[4]: `libmpn.a' is up to date. gmake[4]: Leaving directory `/usr/local/pub-bkb/ghc/fptools/ghc/rts/gmp/mpn' cd mpz; gmake "CC=gcc" "CFLA

Re: FreeBSD port of 4.06

At Mon, 06 Mar 2000 18:43:34 +0900, Yoshiyuki ONOUE <[EMAIL PROTECTED]> wrote: > See . > Same error happened in our 3.3-RELEASE environment. Thank you for updating a freebsd port of ghc-4.06 and I saw "Problem Report ports/17413" to fix a

RE: virtual timers and System.system

> The correct handling would be: > - block SIGALRM/SIGVTALRM/SIGPROF > - *then* fork() (else you have a race condition where the child could > receive *and handle* the signal) This race condition is harmless, I think. The VTALRM handler just increments a counter, and we're about to blow away t

Re: virtual timers and System.system

Hello! On Fri, Mar 17, 2000 at 01:46:03AM -0800, Simon Marlow wrote: > > I don't get it - execve() and friends are supposed to reset > > all the signal > > handlers back to the default state, aren't they? And I can't seem to > > construct an example to demonstrate the problem. > Ah, I get it f

Re: virtual timers and System.system

Hello! On Fri, Mar 17, 2000 at 01:42:14AM -0800, Simon Marlow wrote: > [...] > > After looking at ghc 4.02's libraries for a while (it's all I had > > around), it looks as though ghc-4.02/ghc/lib/std/cbits/system.c should > > mask the SIGVTALRM signal after executing fork and before executing >

RE: virtual timers and System.system

> I don't get it - execve() and friends are supposed to reset > all the signal > handlers back to the default state, aren't they? And I can't seem to > construct an example to demonstrate the problem. Ah, I get it finally :) It's the itimer, not the signal handler that's causing the problem.

RE: virtual timers and System.system

> On FreeBSD using ghc 4.04, long running commands executed with > System.system are being interrupted by virtual alarms leading to > errors such as: > > o Fail: interrupted > Action: system > Reason: system command interrupted rm -f xxx yyy > > o Virtual timer expired > > o gcc: Inter

Re: VTALRM and System.system

Hello! On Thu, Mar 16, 2000 at 04:48:02PM -0700, Alastair Reid wrote: > More through testing of my quick fix (ie trying bigger examples) > revealed that my "trap '' 26" hack failed about 1% of the time. > This being too often (approximately once per program run!) > I hacked up fptools/ghc/lib/s