October 2003 - Glasgow-haskell-users

GHC and gcc 3.3.1
by Peter Simons 20 Oct '03

20 Oct '03

Just curious: Has anyone successfully compiled GHC with gcc 3.3.1 on Linux/x86? I'm having trouble here with both GHC 6.0 and GHC-current. Is that just me? Peter

1 0

RE: Haddock warnings for unresolved prelude functions
by Simon Marlow 20 Oct '03

20 Oct '03

> I'm using Haddock 0.5, compiled for GHC 6.0.1, and I get warnings when > "haddock"ing a simple module: > > Warning: module not found: Prelude > Warning: MyModule: the following names could not be resolved: > Prelude.[] Bool Eq > > I can see what's happening: I'm not passing Prelude.hs to > Haddock, but I'm > using pPrelude functions. But I don't want to pass it a Prelude.hs and > don't want the warnings either. Is there any way to force it to be > silent about unresolved Prelude functions? There isn't a way to make it silent, unfortunately (maybe I'll add one). These warnings are harmless - they just indicate that Haddock couldn't find the right place to link to for these Prelude types. If you want to generate the hyperlinks, then you need the .haddock file for the base package, which is distributed with GHC, and pass the --read-interface flag to Haddock (see the docs for details). Cheers, Simon

2 1

RE: DoCon as GHC test
by Simon Marlow 20 Oct '03

20 Oct '03

> I wonder: why do not you use the DoCon program as the test? No deep reasons, but DoCon is a *lot* of code to include in our nightly builds. Perhaps we should have a large lump of infrequently-run tests, including things like DoCon. Cheers, Simon

1 0

RE: Faster, GHC, and floating point.
by Simon Marlow 20 Oct '03

20 Oct '03

> using -fexcess-precision improves the runtime from about 180259 ns to > 140201 ns on my environment (Intel P3, 700Mhz, 384 MB Ram, Win2k). > That makes for me a speedup of 1.29. I tested the other flags, > -funbox-strict-fields -fliberate-case-threshold100 but did not see an > improvement. > Well, pure Haskell has a runtime of > > 140201 ns > > as stated above for a test of 9000 calls (thanks to the "sum $ map f > [inputlist]" pattern!). If i use the C aibd as foreign call, i get a > runtime of > > 80115 ns > > That's pretty good (both ghc6.0.1 on MinGW windows env). But > if i look at > my Java or C++ solution, then Java takes for the same task > (JVM 1.4.2_01 > client vm) > > 30000 ns. Looking at your code, it looks like you should add some more strictness. eg: sekantenVerfahren :: Funktion -> Genauigkeit -> Genauigkeit -> Int -> Double -> Double sekantenVerfahren f gx gy tiefe start = sekantenIter f tiefe gx gy x1 x2 y1 y2 where x1 = start x2 = start + start * 0.1 y1 = f x1 y2 = f x2 sekantenIter _ 0 _ _ _ x2 _ _ = x2 sekantenIter f tiefe gx gy x1 x2 y1 y2 = let x3 = x2 - y2 * (x2 - x1) / (y2 - y1) y3 = f x3 dy = y3 - y2 dx = x3 - x2 in if (istOk gx x3 dx) && (istOk gy y3 dy) then x3 else sekantenIter f (tiefe-1) gx gy x2 x3 y2 y3 Some of the parameters to the inner recursive function 'sekantenIter' are lazy. Try adding some seqs to help the strictness analyser: sekantenIter _ 0 _ _ _ x2 _ _ = x2 sekantenIter f tiefe gx gy x1 x2 y1 y2 = let x3 = x2 - y2 * (x2 - x1) / (y2 - y1) y3 = f x3 dy = y3 - y2 dx = x3 - x2 in x3 `seq` y3 `seq` dy `seq` dx `seq` if (istOk gx x3 dx) && (istOk gy y3 dy) then x3 else sekantenIter f (tiefe-1) gx gy x2 x3 y2 y3 Cheers, Simon

1 0

RE: Faster, GHC, and floating point.
by Simon Marlow 20 Oct '03

20 Oct '03

> 1. Use -fexcess-precision, unless you really need the > exact (lesser) precision. Otherwise each intermediate > result is spilled in memory. This hurts! There is currently a bug in GHC that the native code generator runs in -fexcess-precision mode all the time (in other words, it doesn't truncate to 64-bit precision like it should do). > 2. Use floats rather than doubles. You won't lose so > much precision because all intermediate computations > will use 80-bit precision. This saves some memory. > Plus, GHC doesn't align on 64 bits, which slows down > access to doubles. It is more-or-less random which intermediate computations will end up using 80-bit precision. You really shouldn't rely on this. The alignment issue is a problem, but we don't have an easy fix. If it weren't for that, the only reason to use Floats would be to save memory. If you get runtimes that vary randomly between two distinct values, the chances are that it's a Double alignment issue. Cheers, Simon

1 0

RE: mips-sgi-irix bootstrapping
by Simon Marlow 20 Oct '03

20 Oct '03

> The solution for the time being is to take the C code generated by > hsc2hs on the host machine using the --no-compile option, > compile & run > the program on the target machine using gcc, then take the .hs back to > the host machine to generate the .hc file. Or you can wait till I've > turned GHC.Unicode back into a plain .hs file. I've now done this, BTW. Cheers, Simon

1 0

RE: Performance Tests in Haskell
by Simon Marlow 20 Oct '03

20 Oct '03

> shure, "caibd" is the called C procedure from AIBD. > well then, i type > > > ghc Main.o AIBD.o HAIBDUtil.o -o HAIBD.exe > > then everything is fine, and i get my executable. > Now i wanted to profile, and added the options "-prof > --auto-all" to the > first ghc command. > When trying to link, i get lot's of undefined references: > > > ghc Main.o AIBD.o HAIBDUtil.o -o HAIBD.exe > > AIBD.o(.text+0x425):ghc1364.hc: undefined reference to `CC_LIST' > AIBD.o(.text+0x430):ghc1364.hc: undefined reference to `CC_LIST' > AIBD.o(.text+0x439):ghc1364.hc: undefined reference to `CC_ID' > AIBD.o(.text+0x444):ghc1364.hc: undefined reference to `CC_ID' > (...) > AIBD.o(.text+0x5fc):ghc1364.hc: undefined reference to `CCCS' > AIBD.o(.text+0x605):ghc1364.hc: undefined reference to `CCCS' > AIBD.o(.text+0x626):ghc1364.hc: undefined reference to > `PushCostCentre' > (...) You forgot to add -prof to the link line, too. Cheers, Simon

1 0

RE: ghc-6.0.1 solaris 2.9 readline problem
by Simon Marlow 20 Oct '03

20 Oct '03

> I've just installed the solaris2.8 binary package for ghc-6.0.1 > > I confess that I am running solaris2.9, which may be the cause of the > problem, in which case I suppose I need to wait. But perhaps > my problem is > more general. I am trying to build HaLeX, a library for > processing automata > and regular expressions. > > I have readline.h and history.h in > /usr/local/include/readline, so the > following error message is puzzling to me: > > HaLeX:make > ghc --make -I./src -i./src -package util -O2 ./src/Main.hs -o > ./bin/halex > Chasing modules from: ./src/Main.hs > Compiling RegExp ( ./src/RegExp.hs, ./src/RegExp.o ) > > ./src/RegExp.hs:20: > Warning: `RegExp' is exported by `RegExp' and `RegExp(..)' > In file included from /tmp/ghc18853.hc:6: > /home/matt/lib/ghc-6.0.1/include/HsReadline.h:5: > readline/readline.h: No such > file or directory > /home/matt/lib/ghc-6.0.1/include/HsReadline.h:6: > readline/history.h: No such > file or directory > make: *** [halex] Error 1 I suspect that GHC isn't looking in /usr/local/include for include files. Adding -I/usr/local/include might help. A better fix is to modify the package configuration for the util package to add "/usr/local/include" to the list of include_dirs. Nobody's fault, really: the GHC package you installed was simply built on a system that had the readline headers installed in a different place. Cheers, Simon

1 0

RE: overlapping instances
by Simon Peyton-Jones 20 Oct '03

20 Oct '03

First thing to say is that I'm changing the way in which overlapping instance errors are reported. At the moment (ghc 6.0, 6.2) you get an overlap error if there *might* be an overlap problem. For example: overlap.hs:23: Overlapping instance declarations: overlap.hs:23: Convertable a String overlap.hs:26: Convertable String a The error is because if the compiler later tried to resolve the constraint (Convertible String String), it would not know which to choose. This is over-eager really. If it tried to resolve (Convertible String Bool) there would be no question of which to choose. GHC 6.4 will report overlap problems lazily, when they actually arise, rather than when they *might* arise. You actually saw; Overlapping instance declarations: Serialise.hs:16: Convertable String a Convertable.hs:7: Convertable a a If the compiler tried to resolve (Convertible String String) it would not know which of the two to use. Hence the error. You also ask: | I do not understand why GHC can't choose between C [Int] (whenever f is | parametrised with Int) or C [a] (whenever f is parametrised with anything | else). GHC has to make the choice once and for all when compiling f, so it can't take advantage of knowing the type at which f is called. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Arie Peterson | Sent: 15 October 2003 21:49 | To: glasgow-haskell-users(a)haskell.org | Subject: overlapping instances | | Hi all, | | In an attempt to design a elegant way to serialise things to any serialised | form, I came up with the following exotic solution: | | ### | {-# OPTIONS -fallow-undecidable-instances -fallow-overlapping-instances #-} | module Convertable where | | class Convertable a b where | convert :: a -> b | | instance Convertable a a where | convert = id | | instance (Convertable a b,Convertable b c) => Convertable a c where | convert = (convert :: b -> c) . (convert :: a -> b) | | class (Convertable a b,Convertable b a) => Equivalent a b | ### | | Happily surprised to see GHC swallow this, I continued by adding | | ### | {-# OPTIONS -fallow-undecidable-instances -fallow-overlapping-instances #-} | module Serialise where | | import Convertable | import Data.PackedString (PackedString,packString,unpackPS) | | instance Convertable String PackedString where | convert = packString | | instance Convertable PackedString String where | convert = unpackPS | | instance (Show a) => Convertable a String where | convert = show | | instance (Read a) => Convertable String a where | convert = read | ### | | But now GHC complains about overlapping instances: | "Overlapping instance declarations: | Serialise.hs:16: Convertable String a | Convertable.hs:7: Convertable a a" | Why can't GHC decide that the "Convertable String a" instance is more specific? | Apparently, there is no problem with the combination of "Convertable a a" | and "Convertable a String": if I leave out "read", all is well. What is the | difference with the above? | | In the manual one can find: | "GHC is also conservative about committing to an overlapping instance. For | example: | class C a where { op :: a -> a } | instance C [Int] where ... instance C a => C [a] where ... | f :: C b => [b] -> [b] f x = op x | From the RHS of f we get the constraint C [b]. But GHC does not commit to | the second instance declaration, because in a paricular call of f, b might | be instantiate to Int, so the first instance declaration would be | appropriate. So GHC rejects the program. If you add | -fallow-incoherent-instances GHC will instead silently pick the second | instance, without complaining about the problem of subsequent instantiations." | I do not understand why GHC can't choose between C [Int] (whenever f is | parametrised with Int) or C [a] (whenever f is parametrised with anything | else). (While checking the type of f, it is clear that the constraint C [b] | is always met.) (Adding -fallow-incoherent-instances did not change anything.) | | Thanks a lot for putting up with my English and my dubious type | constructions :-). | | Regards, | | Arie Peterson | | BTW: I would like to use this opportunity to express my content: I think | haskell is a wonderful language (never, ever anymore javascript :s) and GHC | is a, uhm, glorious compiler :-). | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: ghc 6.3 windows (mingw) cannot invoke gcc correctly
by Simon Peyton-Jones 20 Oct '03

20 Oct '03

I have just installed a fresh mingw, including gcc 3.2.3 from the Mingw download at mingw.org I then did 'make clean;make' on my source tree, and it all worked fine. It's hard to say what is going wrong for you. Are you *very carefully* following the instructions in the building guide? http://www.haskell.org/ghc/docs/latest/html/building/winbuild.html Are you totally up to date in your entire fptools tree? Have you made clean and reconfigured from scratch. (though for the HEAD, you now have to say 'autoreconf' instead of 'autoconf') (And I believe that --build=i386-unknown-mingw32 is better than --host=...) Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of kyra | Sent: 18 October 2003 20:01 | To: glasgow-haskell-users(a)haskell.org | Subject: ghc 6.3 windows (mingw) cannot invoke gcc correctly | | Hi, | | After downgrading a mingw gcc from 3.3.1 to 3.2.3 I've managed to build and | install ghc 6.3 compiler. | | Unfortunately, it cannot compile source files. It seems it incorrectly | invokes gcc . | | "ghc -c -v filt.hs" gives something like this: | | ghc-6.3 (incorrect): | ................... | *** Assembler | g:\Progs\ghc-6.3\gcc -B"g:\Progs\ghc-6.3\gcc-lib/" -I. -I. -c | C:\DOCUME~1\Awson\LOCALS~1\Temp\ghc1252.s -o .\Main.o | | Failed: g:\Progs\ghc-6.3\gcc -B"g:\Progs\ghc-6.3\gcc-lib/" -I. -I. -c | C:\DOCUME~1\Awson\LOCALS~1\Temp\ghc1252.s -o .\Main.orawSystem: does not | exist (No such file or directory) | | ................... | | | ghc-6.0.1 (correct): | ................... | *** Assembler | G:\Progs\ghc-6.0.1\gcc -B"G:\Progs\ghc-6.0.1\gcc-lib/" "-I." "-I." "-c" | "C:\DOCUME~1\Awson\LOCALS~1\Temp\ghc812.s" "-o" "filt.o" | | ................... | | Meanwhile, ghc-6.3 correctly outputs intermediate .c or .s (when compiling | without gcc) files. | | I'm completely stuck. | | Regards, | Kyra | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0