CVS: make all: [MatchPS.o] Segmentation Fault (core dumped)

2000-02-02 Thread Marc van Dongen
Hello again, Just to let you know. When trying to make all from CVS I got the following: make[2]: *** [MatchPS.o] Segmentation Fault (core dumped) make[1]: *** [all] Error 1 make: *** [all] Error 1 I had this before. Re-making will solve the problem. Let me know if more information is

RE: panic! (the `impossible' happened):

2000-02-02 Thread Simon Peyton-Jones
I'm unable to reproduce this. It's a message from inside the code generator, but my freshly-checked out build of the head of the tree compiles fine. I compiled the compiler with 4.06, and then hslibs with the new compiler. I'm not sure what to try next. I guess a ddump-stg would show the

RE: hdirect compilation

2000-02-02 Thread Sigbjorn Finne
Hi, this panic emanates from isn'tIn in utils/Util.lhs. Why this condition merits a compiler panic, I do not know. It is only checked for in DEBUG mode, though. I guess this demonstrates that I've never compiled up hdirect with a version of ghc that itself was compiled with DEBUG on. If the

RE: hdirect compilation

2000-02-02 Thread J.T.Bradley
I guess this demonstrates that I've never compiled up hdirect with a version of ghc that itself was compiled with DEBUG on. If the version of 4.04 you're using is one you've built yourself, I suggest you re-build the contents of ghc/compiler/ without -DDEBUG proceed from there. If that's

RE: CONTRIB/pphs

2000-02-02 Thread Simon Peyton-Jones
It's in fptools/CONTRIB/pphs not fptools/ghc/CONTRIB/pphs Simon | -Original Message- | From: Jan Kort [mailto:[EMAIL PROTECTED]] | Sent: 01 February 2000 11:11 | To: [EMAIL PROTECTED] | Subject: CONTRIB/pphs | | | Hi, | | I tried getting the sources of pphs, cause my version seems to

Re: Haskore installation

2000-02-02 Thread Koen Claessen
John Peterson wrote: | instance Show (a - b) where | showsPrec _ _ = showString " Function " We had the same problem in QuickCheck. When testing properties quantified over functions, we got a type error because suddenly "a - b" is not an instance of Show anymore. Now, if we had taken

Typo in Haskell 98 Random library

2000-02-02 Thread Simon Peyton-Jones
Folks Guess what? I have been driven to the conclusion that the Haskell 98 Random library contains a fundamental, but easily fixed flaw. So I propose to declare a new 'typo'. (Yes, I am all too aware of the danger of typo-creep.) The library is currently based on the RandomGen class, whose

Re: Typo in Haskell 98 Random library

2000-02-02 Thread George Russell
Simon Peyton-Jones wrote: b) genRange (snd (next g)) = genRange g genRange (fst (split g)) = genRange g genRange (snd (split g)) = genRange g I can't see any reason why genRange shouldn't just depend on the type. So why not just specify that genRange _|_ is defined? I think you

Re: Typo in Haskell 98 Random library

2000-02-02 Thread Koen Claessen
Simon Peyton-Jones wrote: | class RandomGen g wher | next :: g - (Int, g) | split :: g - (g, g) If we're fixing bugs in the part about Random.hs in the Haskell'98 library report, we might as well fix the following bug (spotted by John Hughes, but not present at the bug page). About

Re: Typo in Haskell 98 Random library

2000-02-02 Thread D. Tweed
On Wed, 2 Feb 2000, Koen Claessen wrote: gen1 /\ gen1gen2 -- once / || \ gen1 gen2 gen2 gen3 -- twice In fact, they will produce the *same* generator "gen2" on both sides, which will create an undesired dependency between the two

RE: User-defined functionality in Hugs

2000-02-02 Thread Jan de Wit
Would it be possible to supply a function of type String - String which is applied to every non-command input to Hugs? Of course, this function should be the identity by default! Sounds like a great idea. Some thoughts: [big snip] If you don't want to wait for HaskellAST to be implemented,

Typo in Haskell 98 Random library

2000-02-02 Thread Tom Pledger
Hi. RANT Simon Peyton-Jones writes: [...] Suppose next produced output in the range 0..16. (It's specified to produce "at least 30 bits", but the argument still holds.) Suppose we want random numbers in the range 0..10. We can't just take "mod 11" because that would produce too

Re: Typo in Haskell 98 Random library

2000-02-02 Thread Matt Harden
Tom Pledger wrote: Hi. RANT Simon Peyton-Jones writes: [...] Suppose next produced output in the range 0..16. (It's specified to produce "at least 30 bits", but the argument still holds.) Suppose we want random numbers in the range 0..10. We can't just take "mod 11"

Re: Typo in Haskell 98 Random library

2000-02-02 Thread Tom Pledger
Matt Harden writes: Tom Pledger wrote: [...] A similar approach can be taken, for getting uniform deviates (of types in Enum) from a generator in Haskell, without the bias. Just keep applying next, until you get an Int whose 30 trusted bits don't introduce the bias. (You

Re: Typo in Haskell 98 Random library

2000-02-02 Thread Tom Pledger
Another afterthought: Matt Harden writes: [...] compared to just knowing the RNG's range (which is almost always fixed) ahead of time. [...] Yes, it would be useful to know the range ahead of time, so that we don't have to waste the extra guaranteed bits beyond the mandatory 30. Perhaps in