- Jan 24, 2000
-
-
Reuben Thomas authored
Added SGMLSTYLESHEET variable and set SGML2XXX_OPTS to -d $(SGMLSTYLESHEET)
-
Simon Peyton Jones authored
Extra install stuff
-
Simon Marlow authored
Increase the heap size for Parser.hs to 80M (for 4.04).
-
- Jan 23, 2000
-
-
AndyGill authored
GHC now uses the "Hugs" split function, which is believed to have better behaviour: it is not unsafe, is deterministic, and works better with QuickCheck, a major client. Rational for the Record, quoted from Mark Jones mail on the Hugs list: [Mark Jones] A couple of months ago, John Hughes sent me mail about a problem that he had uncovered with the implementation of the Random library in Hugs. He had been using the "split" function in an attempt to generate a stream of random number generators, each of which he hoped would be different from the others. But instead he found that he actually ended with many different copies of the *same* random number generator. A disappointing, and frustratingly non-random result. If you don't happen to recall, split is a member of the RandomGen class, with type RandomGen g => g -> (g,g); it takes a single random number generator as its argument, and returns a pair of two new generators as its result. The only thing that the specification requires is that the two generators returned are (a) distinct and (b) `independently robust' from a statistical point of view. To the best of my knowledge, the implementation in Hugs meets this modest specification. Sadly, assuming only this specification, you cannot write the function that John was looking for and be sure that it will generate more than two different generators. For example, the specification allows even the following trivial implementation for split: split _ = (g1, g2), where g1 and g2 are some arbitrary but constant pair of distinct, and independently robust generators. With this implementation, you can split as often as you want and you'll never get more that two generators. Hugs and GHC (as far as I can tell) both use definitions of the form: split g = (g, f g) for some function f. (My understanding of the code in GHC is that it uses an unsafe function for f, breaking referential transparency; I hope the optimizer knows about this.) Note that this definition returns the argument as a result; the specification doesn't prohibit that; all it requires is that the two results returned be distinct. But if you try to generate a list of n different generators using: take n (iterate (fst . split) g) then you will be sorely disappointed; you might as well have written replicate n g. (On the other hand, if you were lucky enough to have used (snd . split), instead of (fst . split), then you wouldn't have noticed the problem ...) I know very little about the mathematics or pragmatics of random number generators, so I'm not sure that I know how to fix this problem. However, starting from this position of ignorance, I have hacked up a new version of "split" for the standard "StdGen" that will appear in the next release of Hugs (real soon now!). Judging from the tests that I've tried so far, it seems to work much better than the old version. That said: - Take care if you use Random.split in your programs, because it may not do what you expect. - There should probably be an errata about this for the Haskell 98 library report ... if somebody can figure out what it should say. - If you use Hugs, be aware that the implementation of Random.split was hacked up by someone who has no way of justifying that implementation, beyond some simple experiments. - If you know something about the mechanics of random number generators, here's an area where Haskell specifications and implementations could benefit from your knowledge! All the best, Mark [end quote]
-
- Jan 22, 2000
-
-
Simon Marlow authored
Fix bug in async exception handling: the target TSO may have been relocated as a result of a stack overflow. Introduce a new StgTSOWhatNext value "ThreadRelocated", which indicates that this TSO has moved, and the new location is in the link field. The garbage collector shorts these out just like indirections. We have to check for relocated TSOs in killThread# (and any other primops which take a ThreadId# as an argument - there aren't any at present).
-
Simon Marlow authored
- FreeBSD 3+ now known as i386-unknown-freebsd - add alpha-unknown-{linux,freebsd}
-
Simon Marlow authored
freebsd3 ==> freebsd
-
Simon Marlow authored
freebsd3 ==> freebsd
-
Simon Marlow authored
- FreeBSD 3+ is now known as i386-unknown-freebsd (to accomodate forthcoming FreeBSD 4.X - add alpha-unknown-{linux,freebsd}
-
- Jan 20, 2000
-
-
Simon Marlow authored
Remove potentially confusing references to concurrent bundles.
-
Simon Marlow authored
Fairly grotesque hacks to get the HTML docs, which are now generated into a subdirectory by db2html, into a binary dist.
-
Simon Marlow authored
remove ghc/docs/libraries from the bindist, add hslibs/doc
-
Julian Seward authored
trivialCode (x86), when fst arg is immediate, assumed you could reverse the order of operands, but not true for eg subtract. Fixed.
-
Simon Marlow authored
Make this test more comprehensive. We now test +,-,div,mod,quot,rem,gcd,lcm over a range of legal operands, for both Int and Integer.
-
- Jan 19, 2000
-
-
Simon Marlow authored
- add some more test cases, now shows up the minInt bugs in Integer division.
-
Simon Marlow authored
The minInt saga continues: - fix several Integer division-type functions for the case when the dividend == S# (-2147483648#). Pointed out by: Marc Van Dongen <dongen@cs.ucc.ie>
-
Julian Seward authored
amodeToStix: correctly compute offset for CHARLIKE_closure-s.
-
Julian Seward authored
Add comment about code generation for debug tracing.
-
Julian Seward authored
MachCode.stmt2Instrs, StFunBegin, x86 case only: for debugging, generate trace code to print the name of each labelled code block.
-
- Jan 18, 2000
-
-
Julian Seward authored
genCCall for x86 assumed that all args were 4 bytes long :-(. Now works with doubles too.
-
sven.panne@aedion.de authored
Remove `libraries' from SUBDIRS
-
Simon Marlow authored
Remove old libraries documentation.
-
Simon Marlow authored
sync up output
-
Simon Marlow authored
syslib fix
-
Julian Seward authored
Don't spew floating/double literals into assembly output, since this causes difficulties with FP numbers near the edges of the allowed ranges. Instead, convert them to a sequence of bytes and emit those.
-
Simon Marlow authored
syslib fixes.
-
Simon Marlow authored
remove -syslib misc.
-
Simon Marlow authored
fix a few -syslib options.
-
Simon Marlow authored
Don't hold the lock on the Handle while we block waiting for data on a read. This is a partial solution to the general problem of holding a lock on the Handle while in mayBlock.
-
Simon Marlow authored
- ANSIfy - add a couple of comments about dodgy-looking code
-
Simon Marlow authored
ANSIfy
-
Simon Marlow authored
- context switch after a `par` - remove some #if 0'd code
-
Simon Marlow authored
non-functional changes that were sitting in my tree.
-
Simon Marlow authored
update a couple of things.
-
Simon Marlow authored
Don't attempt to split objects built from _stub files. Patch from Michael Weber <michael.weber@post.rwth-aachen.de>.
-
Julian Seward authored
Remove StLitLit, and clean up somewhat the handling of stdout/stderr/stdin in CLitLits (in StixPrim.amodeToStix).
-
- Jan 17, 2000
-
-
Simon Marlow authored
Put a giant loop around awaitEvent, to protect against awaitEvent(rtsTrue) returning with no threads to run. This can happen if we try to delay for some time X, and select(2) decides to wait for a shorter time X-\delta instead. It appears that Solaris is more prone to doing this than Linux. This fixes the "schedule: invalid whatNext field" crashes that people may have seen.
-
Julian Seward authored
Zap a couple of trace-s.
-
Julian Seward authored
Change alignment directives for x86 segment changes to something more plausible-looking for Linux.
-
Julian Seward authored
genCodeInfoTable, genBitmapInfoTable: construct type_info to reflect non-presence of flags in type info field.
-