June 2007 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

ghci and ghc -threaded broken with pipes & forking
by John Goerzen 29 Dec '08

29 Dec '08

Hi, I've been hitting my head against a wall for the past couple of days trying to figure out why my shell-like pipeline code kept hanging. I found fd leakage (file descriptors not being closed), which disrupts EOF detection and can lead to deadlocks. I just couldn't find the problem. I finally tried compiling my test with ghc instead of running it in ghci. And poof, it worked fine the first time. I tried asking on #haskell, and got the suggestion that ghci uses -threaded. I tried compiling my test program with ghc -threaded, and again, same deadlock. My program never calls forkIO or forkOS or any other threading code. You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs That'll run fine. If you add -threaded, it will hang. Ideas? Thanks, -- John

13 44

RTS/Garbage Collector idea
by Isaac Dupree 06 Jul '07

06 Jul '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It's often bothered me that there is unneeded duplication in the heap, if you do something the compiler doesn't manage to optimize like f [a,b,c,d] = Foo bar [a,b,c,d] or (reverse . reverse) or using () or Int(eger) or ... or Bool boxes in multiple places in your program that have the same value. A referentially transparent difference in your program could be the difference between constant memory usage and a memory leak (I think -- although this proposal/idea will not "tie the knot" for you or deal well with cyclic data structures at all, in fact). I was thinking, since we have a copying garbage collector that reassigns all pointers anyway, could we detect the "identical" heap objects and for each set of identical ones, have all thunks that pointed to any of them, now point to the single one that is created in the target space? This might not have much effect. (and seems likely to be slow and possibly have a complex interaction with parallel and/or incremental GC...) Maybe it should not be done on _every_ garbage collection. First to implement/try might be just detecting those duplicates so we have some idea how much effect such an "optimization" would even have. (any idea how easy/possible that is (or just what the answer is;)?) Examples: evaluated (543::Int) somewhere ends up pointing to the same (543# :: Int#) in the heap as another (543::Int) somewhere does. 8:8:2:3:[] 9:9:2:3:[] The []s become shared, then the "3:[]"s, then the "2:3:[]"s, ending 8:8:x 9:9:x where x is 2:3:[] 8:8:2:3:(*) 9:9:2:3:(*) where (*) is the *same* object, maybe an unevaluated thunk, maybe some list. After (*)'s creation, two different parts of code decided to construct their own lists with that as their tail. Eventually becomes: 8:8:x 9:9:x where x is 2:3:(*) Two thunks that merely have the same code shouldn't be combined because it could be the [1..] [1..] sharing memory-leak to the extreme! It would seem safe to combine thunks that only produce something small like an Int, but they can actually produce a complex Exception - so, no combining of thunks. (also... must be careful in this area of breaking the IO monad-sequencing(maybe?), but I think it's quite safe as long as only already-evaluated heap objects are combined) I wonder how this interacts with polymorphic (list-nil of different types), or with merely structurally equivalent, data (if they're identical, merging shouldn't ever be a problem! at least as long as no-one relies on something like "if (unsafe pointer equality) then (same static type)"...) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdmJaHgcxvIWYTTURAjAhAJ9WHwzxuJPuqouol05K7+QHkT3IigCglOpw VtHCSxcy8E+w7OtCafU8pFM= =BqAi -----END PGP SIGNATURE-----

6 6

-keep-hc-files or -keep-hc-file?
by Christian Maeder 02 Jul '07

02 Jul '07

I'm currently confused if it must be plural or singular (or any) http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilatio… shows plural options whereas http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html… shows them in singular (except -keep-tmp-files) Cheers Christian

3 3

readArray is faster than unsafeRead
by Scott Dillard 01 Jul '07

01 Jul '07

Hello, I'm writing some matrix multiplication and inversion functions for small matrices (3x3 and 4x4 mostly, for 3d graphics, modeling, simulation, etc.) I noticed that the matrix multiplication was a bottleneck so I set out to optimize and found that using unsafeRead instead of (!) (or readArray in stateful code) helped a lot. So then I went to optimize my gaussian elimination function and found just the opposite. unsafeRead is slower than readArray. This struck me as very odd considering that readArray calls unsafeRead. If there is a "good" reason why the compiler optimized readArray better than unsafeRead, I'd like to know what it is so that I can make all my array code safe as well as fast. (By "good" reason I mean something deterministic and repeatable, not just luck.) On the otherhand, if this is a fluke, I'm inclined to think that it's not the safe code which is freakishly fast, but the unsafe code which is needlessly slow. That is, something about my program is hindering optimization of the unsafe code. What is it? Attached is the profiling results and a test program with a handful of matrix multiplication and gaussian elimination functions to illustrate what I've seen. This happens both on amd64 and intel core architectures. Thanks for any insight, Scott

5 6

6.6.1 on long lists
by Serge D. Mechveliani 30 Jun '07

30 Jun '07

Dear GHC developers, I tried to test the ghc-6.6.1 performance on long lists. And there is something a bit suspicious about the test. Consider the program ----------------------------------------- main = putStr (shows res "\n") where n = k*10^6 :: Int k = 2 -- put k = 2,4,6, ... res = head $ rev [1 .. n] rev xs = r [] xs where r xs [] = xs r xs (y: ys) = r (y: xs) ys ----------------------------------------- 512 Mb RAM machine, Pentium 4, 1.6 GHz, Debian Linux. `Making': ghc -O --make Main Running time Main +RTS -M400m -RTS ---- ghc-6.6.1 -------------------| k time [sec] minimal needed ghc-5.02.3 for 400Mb heap (-M..) [Mb] 2 1.3 41 2 sec 41 Mb 4 3.0 6 7.8 8 8.8 164 8 ------------------ 10 23.7 12 24.7 244 14 25.1 13 ----------------------------------------------------------------- Should the cost of this program be linear in k ? For example: 8/4 = 2, time(8)/time(4) = 8.8/3.0 =~= 2.9 Should this ratio be near 2.0 ? Further, at k = 10, the time jumps. This is, probably, due to that a list of 10*10^6 ints takes about 8*10*10^6 bytes =~= 80 Mb (please, is this so ?), the program may need a copy of this list ... and this total may be close to -M400M (?), and thus garbage collection happens (once). After k = 10, it looks again like linear. My impression is that at the segment k <- [2, 8] the cost is about k*(log k). Thank you in advance for your comments. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

ghc api, some simple questions
by Claus Reinke 29 Jun '07

29 Jun '07

- {-# OPTIONS_GHC -package ghc #-} would be useful, doesn't give a warning, but doesn't work, either. -package works in ghci, but not in source pragmas, why? - hostSession hardcoding topDir doesn't seem to be a good idea. shouldn't GHC export means to get at the "hosting" ghc session (the one compiling the current code), so that one could ask for topDir there? currently, i'm calling "ghc --print-libdir" externally .. if nothing else, perhaps something like the 'ghcDir' hack from the example below could be in GHC? - ppr/printForUser should GHC reexport Outputable? also, ppr doesn't seem to handle infix op definitions correctly, printing the left-hand side in prefix form, but without parentheses? [ghc 6.6.1] claus ----------------------------------------------------- {-# OPTIONS_GHC -package ghc #-} module API where import DynFlags import GHC import System.Process import System.IO import Outputable mode = Interactive -- shouldn't something like this be in System.Process? writer >| cmd = runInteractiveCommand cmd >>= \(i,o,e,p)->writer i cmd |> reader = runInteractiveCommand cmd >>= \(i,o,e,p)->reader o -- shouldn't GHC export a hostSession, -- so that we could ask for things like topDir there? ghcDir = "ghc --print-libdir" |> (fmap dropLineEnds . hGetContents) where dropLineEnds = filter (not . (`elem` "\r\n")) main = defaultErrorHandler defaultDynFlags $ do s <- newSession mode . Just =<< ghcDir flags <- getSessionDynFlags s (flags, _) <- parseDynamicFlags flags ["-package ghc"] GHC.defaultCleanupHandler flags $ do setSessionDynFlags s flags{ hscTarget=HscInterpreted } addTarget s =<< guessTarget "API.hs" Nothing load s LoadAllTargets prelude <- findModule s (mkModuleName "Prelude") Nothing usermod <- findModule s (mkModuleName "API") Nothing setContext s [usermod] [prelude] Just cm <- checkModule s (mkModuleName "API") unqual <- getPrintUnqual s printForUser stdout unqual $ ppr $ parsedSource cm

1 0

GHC 6.6.1 Build failure on plain vanilla linux i686 build
by Robin Bate Boerop 29 Jun '07

29 Jun '07

My build dies very soon after issuing "make". Here are the last few lines. Does anyone know what is happening and how to fix it? (The floating constant of which the error message speaks is __GHC_PATCHLEVEL__, which is set to 2.20060331.) I have a working GHC 6.4 installed, BTW. /sec/bin/ghc -optc-O -optc-I. -optc-Iinclude -optc-D__GHC_PATCHLEVEL__=2.20060331 -optc-I../libraries/base/cbits -optc-I../libraries/base/include -H16m -O -I. -Iinclude -Rghc-timing -ignore-package Cabal -I../libraries -fglasgow-exts -no-recomp -c cbits/unicode.c -o cbits/unicode.o cbits/unicode.c:1:63: error: floating constant in preprocessor expression <<ghc: 13597044 bytes, 3 GCs, 103440/103440 avg/max bytes residency (1 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (0.17 elapsed), 0.01 GC (0.02 elapsed) :ghc>> make[2]: *** [cbits/unicode.o] Error 1 make[1]: *** [boot] Error 2 make: *** [stage1] Error 1

2 3

Re: 64-bit windows version?
by Peter Tanski 26 Jun '07

26 Jun '07

> skaller wrote: > >> On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote: >> >>> Bulat Ziganshin wrote: >>> >>>> Hello glasgow-haskell-users, >>>> >>>> are you plan to implement 64-bit windows GHC version? >>>> >>> The main thing standing in the way of this is the lack of a 64- >>> bit port of >>> mingw. >>> >> >> Why do you need mingw? What's wrong with MSVC++? The largest problem is the build system: GHC uses autoconf with custom makefiles. I have looked into porting the whole thing to a Visual Studio project, using SCons (unreliable), CMake (limited command line abilities--good for a one-shot build but really just a "safe" lowest-common-denominator version of Make), Waf (another python-based build system that started as a fork of SCons for the KDevelop changeover from Autotools) and Jam. I would prefer to use Jam but I'm afraid I would be the only one who would ever want to support it. Nothing has the auto-configuration abilities you (John) built into the Felix Interscript-based system but I do not porting the build system (at least) to Interscript would go over well with anyone else who wanted to maintain it and the build itself would require heavy customisation. I have tested all of these on a small scale (the replacement-Integer library). The best option seems to be to create a VS project (not trivial--lots of glue) so a user may also call that from Make (if under Mingw) or pure DOS. There is also some gcc-specific code in the RTS (inline assembler, use of extern inline, etc.) By the way, as of gcc-4.2 (I believe; I know it is true for gcc-4.3) the use of 'extern inline' now conforms strictly to the C99 standard so we will have to add the option '- fgnu-89-inline' to get the old behaviour back--'extern inline' is used in some of the headers. Converting those 'extern inline's to 'static inline' or best yet plain 'inline' would also solve the problem. Ian Taylor's message at http://gcc.gnu.org/ml/gcc/2006-11/ msg00006.html describes this in greater detail; his proposal was implemented. > I don't think we'll be able to drop the mingw route either, mainly > because while > the MS tools are free to download, they're not properly "free", and > we want to > retain the ability to have a completely free distribution with no > dependencies. I don't know of any completely free 64-bit compilers for Windows. The Intel compilers are free for 30-day evaluation but everything else is for Win32. For the base Win32-native port there are many compilers available but I have mostly worked on using CL and Yasm (assembler) as replacement back-end compilers for GHC. > There are people that want a Cygwin port too; personally I think > this is heading > in the wrong direction, we want to be more "native" on Windows, > using the native > object format and interoperating directly with the native Windows > tools. Cygwin has a real problem with gcc: it is far behind everything else (gcc-3.4.4, though Mingw isn't much better) and it doesn't look like that will change anytime soon. It is also only 32-bit, I believe. Cheers, Pete

8 29

hpux 11.0 floating point alignment problem in PrimOps.cmm
by Joe Buehler 26 Jun '07

26 Jun '07

I am getting a floating point alignment exception during a GHC 6.4.2 bootstrap on hpux 11.0 -- the stage 1 ghc core dumps. The stack trace looks like this: (gdb) where #0 0x1ac0df8 in __gmpn_mul_1 () #1 0x1abdd24 in __gmpz_mul () #2 0x1aa2ef4 in timesIntegerzh_fast () #3 0x1ab8124 in StgRun () #4 0x1a9bc08 in schedule () #5 0x1a9c5f4 in waitThread_ () #6 0x1a9c52c in scheduleWaitThread () #7 0x1a99a88 in rts_evalLazyIO () #8 0x1a990dc in main () (gdb) The timesIntegerzh_fast routine is calling into libgmp, libgmp is then core dumping because of an access to a double with bad alignment -- it is trying to load a double from a 4-byte aligned address -- hpux requires 8 byte alignment. The code for timesIntegerzh_fast comes from PrimOps.cmm. It is making use of these memory locations: section "bss" { mp_tmp1: bits8 [SIZEOF_MP_INT]; } section "bss" { mp_tmp2: bits8 [SIZEOF_MP_INT]; } section "bss" { result1: bits8 [SIZEOF_MP_INT]; } section "bss" { result2: bits8 [SIZEOF_MP_INT]; } Might this alignment problem be fixed by adding in some "align 8" statements? Joe Buehler

1 0