- Glasgow-haskell-users

Re: ghc-testsuite-6.6 on Macs
by Thorkil Naur 21 Nov '06

21 Nov '06

Hello, On Tuesday 14 November 2006 11:34, Simon Marlow wrote: > Thorkil Naur wrote: > > ... I have > > produced an experimental darcs patch that solves some problems, while > > possibly introducing others: > > http://thorkilnaur.dk/~tn/GHC/testsuite/patch/barton_mangler_bug_patch_1.pa… . > > Comments to this would be most welcome. > > For those who haven't looked at Thorkil's patch: he proposes adding some code to > the testsuite driver to allow sample output specific to a particular way, and > used this to give sample output for one test (barton-mangler-bug) specific to > the 'opt' way on PPC. > > I would like it to be the case that any differences at all in the output from > one way to another are bugs, including floating point differences. It is a basic question of what varying circumstances we believe should be handled by the test framework. I tend to agree with you and, hence, to reject my own suggestion of extending the testsuite driver to allow different output for different ways.. > On x86_64, > we always generate the same results regardless of -fvia-C or -fasm, for example. > However, it might be that this isn't practical on all platforms. I feel rather sure that it isn't. > The question > is whether we should consider it a *bug* if a test doesn't give consistent > floating-point answers or not. Anyone have any thoughts on this? Let me put it in this way: It is well known that it is almost always bad to test whether two floating point numbers are exactly equal. So in this sense, a test whose outcome depends on testing whether two floating point numbers are exactly equal is a bad test. (Converting floating point numbers to decimal strings and comparing the strings which is what really happens seems to make matters even worse.) To be sure, if we are really testing the floating point operations, we are of course entitled to test equality. But if a test does not deal with floating point operations as such, but merely includes floating point numbers in its output incidentally, the test is probably bad. I cannot see that the Haskell report specifies precise properties of the floating point support, so even implementations that conform to the standard (Haskell 98) can be expected to differ. Hence, any test that involves output of floating point numbers might produce different output for reasons that are entirely unrelated to the test, not a particularly appetizing situation. Whether difference in floating point results between different ways should be considered a bug in GHC, I cannot say. I would tend towards "no", but that is probably because I don't have any particular intense interest in floating point numbers. Getting finally to something more specific, my impression until your question here had been that the barton-mangler-bug test involved floating point numbers incidentally: I imagined that someone (named Barton, perhaps?) ran this program at some point in time, discovered some unfortunate behaviour (such as the program crashing or producing wild results), that this behaviour was traced down to an error in some mangler (the gcc assembler language output "post processor"), and that the test was included and maintained in the testsuite to ensure that this bug was thouroughly stamped out. Based on your question, I realised that my impression could be entirely false and that the central property tested was precisely the floating point differences observed for some ways. I am still in doubt, so if anyone knows the story behind the barton-mangler-bug, I would be delighted to hear it. > > If it's a bug, then we just declare these tests to be expected failures. If > it's not a bug, then we have to allow per-way sample output, as per Thorkil's patch. > As I have already mentioned, I think my patch is a mistake. Depending on what anyone can tell me about the barton-mangler-bug, additional work would seem to go in one of two directions: If the floating point numbers are involved incidentally and the mangler bug still threatens, work should attempt to remove the floating point numbers from the output and produce a test case that exposes the bug more succinctly. I would certainly need some additional help to do this. On the other hand, if the floating point difference between, e.g., opt and normal is the real issue, it would still seem advantageous and quite possible to reduce the size of the test case, to make it easier to figure out the cause of the difference. > Cheers, > Simon > Best regards Thorkil

2 1

RTS -I switch
by Bulat Ziganshin 20 Nov '06

20 Nov '06

Hello glasgow-haskell-users, i still forget to ask: if my program is idle during long time, is GC will occur each 0.3 seconds or GHC is smart enough to check that no much memory was allocated after last GC? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 3

Major type-class overhaul
by Simon Peyton-Jones 20 Nov '06

20 Nov '06

Dear GHC users, For some time I have been promising an overhaul of GHC's type inference machinery to fix the interactions between type classes and GADTs. I've just completed it (or at least I hope so). This message is just to summarise the programmer-visible changes, and to encourage you to give them a whirl. Of course, you'll need to compile the HEAD to do this; or get a nightly-build snapshot in a day or two's time. Needless to say, if you are using the HEAD for mission-critical stuff, proceed with caution. I don't guaranteed bug-free-ness. Simon This major patch adds implication constraints to GHC's type inference mechanism. (The name "implication constraint" is due to Martin Sulzmann.) >From a programmer point of view, there are several improvements 1. Complete(r) type inference ~~~~~~~~~~~~~~~~~~ GHC's type inference becomes complete (or perhaps more complete!) Particularly, Karl-Filip Faxen's famous example in "Haskell and principal types" (Haskell workshop 2003) would type check when the program text was written in one order, and then fail when the text was re-ordered. Now it works regardless. The test is tc218. 2. Lifting the "quantified-here" restriction ~~~~~~~~~~~~~~~~~~~~~~~~~ The restriction that every constraint in a type signature must mention at least one of the quantified type variables is lifted. So you can write f :: C Int => ... or g :: forall b. Eq a => ... This may seem odd, but the former was recently requested by a Haskell user; see this message: http://www.haskell.org/pipermail/glasgow-haskell-users/2006-September/01113… 3. Dictionaries are packaged in data constructors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A very useful new feature is this. When a data type is declared in in GADT syntax, the context of the constructor is *required* when constructing *available* when matching For example data T a where T1 :: Num a => a -> T a T2 :: Bounded a => T a f :: T a -> a f (T1 x) = x+1 f T2 = maxBound Notice that f is not overloaded. The Num needed in the first branch is satisfied by the T1 pattern match; and similarly for the T2 pattern match. This feature has been often requested, becuase it allows you to package a dictionary into an ordinary (non-existential) data type, and be able to use it. NOTE: the Haskell 98 syntax for data type declarations data Num a => T a = T1 a behaves exactly as specified in H98, and *not* in the new way. The Num dictionary is *required* when constructing, and *required* when matching I think this is stupid, but it's what H98 says. To get the new behaviour, use GADT-style syntax, even though the data type being defined is does not use the GADT-ness. 4. Type classes and GADTs ~~~~~~~~~~~~~~~~~ The proper interaction between GADTs and type classes is now respected. For example: data GADT a where MkG :: Num a => a -> GADT [a] g :: forall b. Read b => GADT b -> String -> b g (MkG n) s = n : read s Inside the branch we know that b=[a], so the (Read b) dictionary is a (Read [a]) dictionary, which is why we can use the result of read in the tail of a cons. Functional dependencies and equality predicates ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The treatment of functional dependencies is still ad hoc and unsatisfactory. I do not promise that they will work nicely in conjunction with GADTs. Trac #345 has a good example. More generally, we want to add - indexed type synonyms (aka associated type synonyms) - equality constraints in contexts Both will require us to furher overhaul constraint handling. So this patch is just a (big) step on the way.

7 7

GHC 6.6 on Ubuntu
by Chad Scherrer 19 Nov '06

19 Nov '06

Is there a preferred way of getting this going? I tried the GHC instructions for Debian, but this seems to depend on 6.6 already being in the repository, which it's not, in Ubuntu (why?). I like Debian/Ubuntu's install system, and I assume that 6.6 will eventually make it into Ubuntu. I want to be sure whatever I do now doesn't later confuse the system. Thanks, Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

3 2

Re: [Haskell-cafe] Debugging partial functions by the rules
by Neil Mitchell 18 Nov '06

18 Nov '06

Hi > To see at a glance the various bug reports about fromJust you can > search the bug database: > http://bugs.darcs.net/issue?@columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassi… > > I count 7 bugs. > I would be interested to see the results of static analysis tools > (Catch?) or applying Oleg's strategy. Any volunteers? Unfortunately darcs is too big, and too unhaskell-98 to go through Catch as it currently stands. In reality the best strategy would probably be to use Catch on darcs, then where Catch is unable to automatically verify the program use Oleg's techniques and other rewritings until Catch can verify everything. Just taking a random example (the first fromJust I stumbled upon): http://abridgegame.org/repos/darcs-unstable/Population.lhs, cleanPop The requirement here is that the modifiedHowI field of the 2nd field of the Pop at the top must be not a removal. Figuring out in an existing code-base whether that is a general invariant for Pop, true in this specific case, or any other random combination is quite a hard problem! Thanks Neil

1 0

Problem running X11 on PPC Mac
by Melissa Chase 17 Nov '06

17 Nov '06

I'm new to Haskell (and GHC) and am not sure if this is the appropriate place to post this (or if it should be reported as a bug). Yesterday I downloaded the binary build of 6.6 for the PPC Mac. I am running Mac OSX 10.4.8. I have XCode 2.4.1 and X11 1.1 installed. I was trying to get the graphics for SOE working and tried the first SimpleGraphics module. I used "import Graphics.SOE" and once I discovered that I had to set DYLD_LIBRARY_PATH to the X11 libraries (in /usr/X116/lib), the module loaded in ghci. When I tried to run main0, I got the following error message: Loading package X11-1.1 ... linking ... <interactive>: /opt/local/lib/ghc-6.6/HSX11_cbits.o: unknown symbol `_printf$LDBLStub' ghc-6.6: unable to load package `X11-1.1' I ran nm on that object file and the symbol appears in it as undefined, and is not defined in any of the .o or .a files in the ghc lib directory. I subsequently built the DarwinPorts version of ghc 6.6 and have the same problem. Penny

5 12

higher rank polymorphism
by Jan Christiansen 17 Nov '06

17 Nov '06

Hi, I want to use a rank 2 data type and end up in typ problems that I don't understand. I would really appreciate any hints to the presented cases or pointers to interesting papers that address the background of these problems. I define the following datatype and a simple function that checks whether the list is empty. data Test = Test (forall a . [a -> a]) null1 :: Test -> Bool null1 (Test []) = True null1 (Test _) = False null2 :: Test -> Bool null2 (Test l) = null l null3 :: Test -> Bool null3 (Test l) = case l of [] -> True _ -> False For null1 ghc reports the following typeerror: Couldn't match expected type `forall a. [a -> a]' against inferred type `[a]' In the pattern: [] In the pattern: Test [] In the definition of `null1': null1 (Test []) = True while null2 and null3 don't cause errors. I don't understand why there is a difference between these definitions of null. cp1 :: Test -> Test cp1 (Test l) = case l of [] -> Test [] (x:xs) -> Test (x:xs) cp2 :: Test -> Test cp2 (Test l) = if null l then Test [] else Test (head l:tail l) For cp1 ghc reports the following typeerror: Inferred type is less polymorphic than expected Quantified type variable `a' is mentioned in the environment: xs :: [a -> a] (bound at UpDownTree.hs:36:10) x :: a -> a (bound at UpDownTree.hs:36:8) In the first argument of `Test', namely `(x : xs)' In the expression: Test (x : xs) In a case alternative: (x : xs) -> Test (x : xs) while for cp2 ghc doesn't report an error. I guess there is a similar reason for this error as for the error for null1. I now want to restrict the polymorphic functions in the data type to types for which there is an instance of the type class Eq. data TestEq = TestEq (forall a . Eq a => [a -> a]) null4 :: TestEq -> Bool null4 (TestEq l) = null l For null4 ghc reports the following typeerror: Ambiguous type variable `a' in the constraint: `Eq a' arising from use of `l' at UpDownClass.hs:37:24 Probable fix: add a type signature that fixes these type variable (s) I obviously cannot add a constraint that constraints a type variable that doesn't occur in the type of null4. I will be very pleased for any hints. Regards, Jan

2 2

ghc-testsuite-6.6 on Macs
by Christian Maeder 16 Nov '06

16 Nov '06

Did someone run the test-suite of the binary distributions? http://www.haskell.org/ghc/dist/6.6/ghc-6.6-ppc-apple-darwin.tar.gz http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin.tar.bz2 I've build a (ppc-) mac-distribution from sources and my results are shown below. I had the following 3 unexpected failures under linux, too (by using "make TEST_HC=<installed ghc>" and the <installed ghc> was from http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-unknown-linux.tar.bz2) cg058(ghci) ghcpkg01(normal) ghcpkg03(normal) I thought the failure signals002(ghci) was related to http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/10947 In fact, I needed to kill the ghc-process to continue the tests. The test files cc004.hs and ffi012.hs failed with several messages of the form: calling convention not supported on this architecture: stdcall When checking declaration: foreign import stdcall safe "wrapper" wrap_f :: F -> IO (FunPtr F) However, they did not make it into the summary Cheers Christian OVERALL SUMMARY for test run started at Mon Oct 23 14:54:15 CEST 2006 1455 total tests, which gave rise to 6441 test cases, of which 0 caused framework failures 1126 were skipped 5242 expected passes 55 expected failures 3 unexpected passes 15 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm,profasm) Unexpected failures: barton-mangler-bug(opt) cabal02(normal) cg058(ghci) conc019(opt,profasm) conc024(opt) ffi009(ghci) forkprocess01(ghci) galois_raytrace(opt,prof) ghcpkg01(normal) ghcpkg03(normal) joao-circular(prof,profasm) signals002(ghci)

4 7

Debugging partial functions by the rules
by dons＠cse.unsw.edu.au 15 Nov '06

15 Nov '06

So all this talk of locating head [] and fromJust failures got me thinking: Couldn't we just use rewrite rules to rewrite *transparently* all uses of fromJust to safeFromJust, tagging the call site with a location? To work this requires a few things to go right: * a rewrite rule * assertions * and rewrite rules firing before assertions are expanded Let's try this. Consider the program: 1 import qualified Data.Map as M 2 import Data.Maybe 3 4 main = print f 5 6 f = let m = M.fromList 7 [(1,"1") 8 ,(2,"2") 9 ,(3,"3")] 10 s = M.lookup 4 m 11 in fromJust s When we run it we get the not so useful error: $ ./A A: Maybe.fromJust: Nothing Ok, so we have a few tricks for locating this, using LocH (http://www.cse.unsw.edu.au/~dons/loch.html) we can catch an assertion failure, but we have to insert the assertion by hand: 1 import Debug.Trace.Location 2 import qualified Data.Map as M 3 import Data.Maybe 4 5 main = do print f 6 7 f = let m = M.fromList 8 [(1,"1") 9 ,(2,"2") 10 ,(3,"3")] 11 s = M.lookup 4 m 12 in safeFromJust assert s 13 14 safeFromJust a = check a . fromJust Which correctly identifies the call site: $ ./A A: A.hs:12:20-25: Maybe.fromJust: Nothing Now, this approach is a little fragile. 'assert' is only respected by GHC if -O is *not* on, so if we happened to try this trick with -O, we'd get: $ ./A A: Debug.Trace.Location.failure So lesson one: you have to do the bug hunting with -Onot. Currently there's -fignore-asserts for turning off assertions, but no flag for turning them on with -O, Simon, could this be fixed? Could we get a -frespect-asserts that works even with -O ? Ok, assuming this assert trick is used, can we get the compiler to insert the asserts for us? If so, this would be a great advantage, you'd just be able to switch on a flag, or import a debugging module, and your fromJusts would be transparently rewritten. With rewrite rules we do just this! So, to our initial unsafe use of fromJust, we add a rewrite rule: -- -- rewrite fromJust to a located version, and hope that GHC expands -- 'assert' after the rule fires.. -- {-# RULES "located fromJust" fromJust = check assert . myFromJust #-} This just tells the compiler to replace every occurence of fromJust with a assertion-throwing fromJust, should it fail. We have to use myFromJust here, to avoid rule recursion. -- -- Inlined to avoid recursion in the rule: -- myFromJust :: Maybe a -> a myFromJust Nothing = error "Maybe.fromJust: Nothing" -- yuck myFromJust (Just x) = x Ok, so can we get ghc to rewrite fromJust to the safe fromJust magicaly? $ ghc --make -Onot A.hs -fglasgow-exts -ddump-simpl-stats [1 of 1] Compiling Main ( A.hs, A.o ) 1 RuleFired 1 located fromJust Linking A ... Yes, the rule fired! GHC *did* rewrite our fromJust to a more useful fromJust. Running it: $ ./A A: A.hs:19:36-41: Maybe.fromJust: Nothing Looks good! But that is deceiving: the assert was expanded before the rule fired, and refers to the rewrite rule source line (line 19), not the fromJust call site (line 12). Now if we could just have the 'assert' token inserted into the AST before it was expanded, we'd be home and dry. Could this be done with TH? Or could we arrange for asserts in rewrite rules not to be expanded till later? Note that this is still a useful technique, we can rewrite head/fromJust/... to some other possibly more useful message. And if we can constrain the rule to fire in only particular modules, we may be able to narrow down the bug, just by turning on a rule. For example, adding: {-# RULES "located fromJust" fromJust = safeFromJust #-} safeFromJust s = case s of Nothing -> "safeFromJust: failed with Nothing. Ouch" Just x -> x will produce: $ ./A "safeFromJust: failed with Nothing. Ouch" So rewrite rules can be used to transparently alter uses of partial functions like head and fromJust. So, further work: * have 'assert' respected when -O is on * think up a technique for splicing in 'assert' via rewrite rules (or TH ...) such that the src locations are expanded after the rewrite, and correctly reflect the location of the splice point. Any ideas? -- Don

3 4

Re: The wiki [was : fromJust something something]
by Serge D. Mechveliani 15 Nov '06

15 Nov '06

I have put there my message. Thank you. But, generally, I do not understand this `wiki' idea (if this is of wiki). 1. People (like myself) will pollute the Debugging Page, or such, with badly edited and erroneous `draft' ideas, and then, who would like to read this page? 2. I edited this Page by adding my message. And what if some user removes all messages, editing the Page to empty? ----------------- Serge Mechveliani mechvel(a)botik.ru On Wed, Nov 15, 2006 at 10:27:59AM +0000, Simon Peyton-Jones wrote: > Way better thank you. Serge -- just follow the links for instructions! > > [..] > | > | We should be able to add this to the 'help' button, > | > | http://www.haskell.org/haskellwiki/Help:Contents > | > ... > | > | Now this is strange. The 'Help' link should be on every page, along with > | > | the 'Login' button?

3 2