April 2001 - Cvs-hugs

cvs commit: hugs98/src compiler.c output.c
by Andy Gill 30 Apr '01

30 Apr '01

andy 2001/04/30 12:41:35 PDT Modified files: src compiler.c output.c Log: More changes toward having a good intermeduate output format from Hugs. Revision Changes Path 1.6 +81 -3 hugs98/src/compiler.c 1.18 +7 -8 hugs98/src/output.c

1 0

cvs commit: hugs98/src compiler.c output.c static.c type.c
by Andy Gill 26 Apr '01

26 Apr '01

andy 2001/04/26 18:00:36 PDT Modified files: src compiler.c output.c static.c type.c Log: First pass at producing machine readable supercombinator output. This output is used by the Snowball compiler. Revision Changes Path 1.5 +3 -3 hugs98/src/compiler.c 1.17 +116 -48 hugs98/src/output.c 1.35 +4 -4 hugs98/src/static.c 1.32 +4 -5 hugs98/src/type.c

1 0

cvs commit: hugs98/tests Readme
by Alastair Reid 24 Apr '01

24 Apr '01

reid 2001/04/24 19:42:32 PDT Modified files: tests Readme Log: Tweaked documentation Revision Changes Path 1.2 +8 -2 hugs98/tests/Readme

1 0

cvs commit: hugs98/tests Readme
by Alastair Reid 24 Apr '01

24 Apr '01

reid 2001/04/24 19:35:33 PDT Added files: tests Readme Log: Added documentation for testsuite

1 0

cvs commit: hugs98/tests testScript.in hugs98/tests/static mod75.output
by Alastair Reid 22 Apr '01

22 Apr '01

reid 2001/04/22 14:22:53 PDT Modified files: tests testScript.in tests/static mod75.output Log: Closing out this alleged error. Sigbjorn persuaded me that Hugs is consistent with the report. (I had checked the first bullet of section 5.5.1 of the report but had been distracted by the 2nd half of the bullet.) Revision Changes Path 1.3 +1 -1 hugs98/tests/testScript.in 1.2 +0 -1 hugs98/tests/static/mod75.output

1 0

cvs commit: hugs98/docs .cvsignore hugs98/src .cvsignore hugs98/src/unix .cvsignore
by Alastair Reid 21 Apr '01

21 Apr '01

reid 2001/04/21 13:02:31 PDT Added files: docs .cvsignore src .cvsignore src/unix .cvsignore Log: Added .cvsignore files - can't see what's new with all that noise from make/config-generated files

1 0

cvs commit: hugs98/tests/rts enum.output enum.output1 enum.output2 infix.output print1.output print2.output hugs98/tests/static mod61.output hugs98/tests/tcheck DictHW.output
by Alastair Reid 21 Apr '01

21 Apr '01

reid 2001/04/21 12:46:51 PDT Modified files: tests/rts enum.output enum.output1 enum.output2 infix.output print1.output print2.output tests/static mod61.output tests/tcheck DictHW.output Log: Closed out a number of errors being reported by the test suite by deciding that Hugs was behaving correctly in all cases and updating the expected output accordingly. Revision Changes Path 1.2 +4 -4 hugs98/tests/rts/enum.output 1.2 +4 -4 hugs98/tests/rts/enum.output1 1.2 +4 -4 hugs98/tests/rts/enum.output2 1.2 +1 -1 hugs98/tests/rts/infix.output 1.2 +6 -6 hugs98/tests/rts/print1.output 1.2 +6 -6 hugs98/tests/rts/print2.output 1.2 +1 -1 hugs98/tests/static/mod61.output 1.2 +4 -1 hugs98/tests/tcheck/DictHW.output

1 0

Re: cvs commit: hugs98/src subst.c
by Alastair Reid 21 Apr '01

21 Apr '01

> lewie 2001/04/18 10:01:53 PDT > > Modified files: > src subst.c > Log: > Expand type synonyms when looking for a Show instance at top-level. > > Revision Changes Path > 1.19 +3 -2 hugs98/src/subst.c Could you add an appropriate test to the test suite please? (Yeah, I know it's a bore but a big test suite makes maintenance much easier and with all of us having less and less time to do the full job...) [While on the subject, a few tests for implicit parameters would be great.] -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

1 0

cvs commit: hugs98/lib/exts ConcBase.hs hugs98/tests/rts mvar.hs mvar.input mvar.output
by Alastair Reid 21 Apr '01

21 Apr '01

reid 2001/04/21 11:23:24 PDT Modified files: lib/exts ConcBase.hs tests/rts mvar.hs mvar.input mvar.output Log: Implemented the new GHC putMVar semantics and updated test suite Revision Changes Path 1.7 +32 -18 hugs98/lib/exts/ConcBase.hs 1.2 +18 -1 hugs98/tests/rts/mvar.hs 1.2 +1 -0 hugs98/tests/rts/mvar.input 1.2 +4 -1 hugs98/tests/rts/mvar.output

1 0

cvs commit: hugs98/lib/exts ConcBase.hs
by Alastair Reid 20 Apr '01

20 Apr '01

reid 2001/04/20 17:18:30 PDT Modified files: lib/exts ConcBase.hs Log: 2nd (and last) commit in this series. Added new MVar operations: tryTakeMVar and tryPutMVar. These have not been tested very thoroughly. We need one other change to make Hugs fully compatible with GHC: GHC recently(?) changed the behaviour of putMVar on a full variable. This used to raise an exception but now it's supposed to block. This is going to take a little pondering. At the moment, an MVar is: newtype MVar a = MkMVar (IORef (Either a [a -> IOResult])) That is, it's either full or it's a (possibly empty) queue of blocked threads. To accomodate the new semantics, it should change to something like: newtype MVar a = MkMVar (IORef (Either (a, [(a,IOResult)]) [a -> IOResult])) where Left (x, ts) represents a full mvar with a (possibly empty) list ts of blocked putters (and the values they want to put). Right ts represents an empty mvar with a (possibly empty) list ts which want to receive a value. Then we have to make putMVar block - with luck the mechanism used to block in takeMVar will work. And then we have to ponder the question of fairness: My original MVar implementation made no attempt to unblock threads in the same order as they had blocked. In fact, they could be unblocked in exactly the opposite order from the order in which they had blocked. At the time, I argued that this was the correct behaviour since it was so manifestly unfair that no-one was going to be fooled into believing that Hugs' "scheduler" was fair. I felt this was a good idea because it just wasn't possible to achieve fairness with a non-preemptive implementation and I'd rather have my code always fail than occasionally fail. But the moment my back was turned (:-)), the OGI folks made MVars fairer. I imagine they much have had a reason to do this ... Maybe I should preserve this fairness in the interest of not breaking anything. [Incidentally, a recent bug report on the ghc list suggests that ghc's MVars aren't fair either. This code: forkIO (mapM_ putChar as) >> forkIO (mapM_ putChar bs) where as = 'a':as; bs = 'b':bs will output either all as or all bs. It seems that 'mapM putChar as' spends almost all its time inside a mutex (protecting the stdout object) and that when 'mapM putChar bs' tries to acquire the same lock, it always fails. The GHC folk are considering changing putMVar (I think) to consider preempting if there were any threads blocked on the mvar. ] Revision Changes Path 1.6 +42 -1 hugs98/lib/exts/ConcBase.hs

1 0