- Glasgow-haskell-users

GHC platforms
by Simon Marlow 20 Apr '06

20 Apr '06

I've put up a wiki page listing the platforms that GHC supports and which features are supported on each platform: http://hackage.haskell.org/trac/ghc/wiki/Platforms I've no doubt made mistakes and there are a few empty boxes where I wasn't sure. Please improve the information here if you can. This replaces the section in the Building Guide that was becoming rather out of date. Cheers, Simon

2 1

no ghc-6.4.2 under solaris
by Christian Maeder 20 Apr '06

20 Apr '06

Hi, my stage2 compiler under solaris is unusable. "gmake bootstrap3" does not terminate and even compiling the simplest file does not terminate: Christian -bash-3.00$ ghc -v --make hello.hs Glasgow Haskell Compiler, Version 6.4.2, for Haskell 98, compiled by GHC version 6.4.2 Using package config file: /local/home/maeder/ghc-6.4/lib/ghc-6.4.2/package.conf Using package config file: /home/maeder/.ghc/sparc-solaris2-6.4.2/package.conf Hsc static flags: -static *** Chasing dependencies: Chasing modules from: hello.hs Stable modules: *** Compiling Main ( hello.hs, interpreted ): compile: input file hello.hs *** Checking old interface for Main: Compiling Main ( hello.hs, hello.o ) *** Parser: *** Renamer/typechecker: [waited] ^C*** Deleting temp files Deleting: /tmp/ghc8103.hc Warning: deleting non-existent /tmp/ghc8103.hc

1 0

IORefs and garbage collection
by Ravi Nanavati 20 Apr '06

20 Apr '06

I recently discovered that I'm running into the IORef / garbage collection issue described in the ghc user guide (at the bottom of the following page): http://www.haskell.org/ghc/docs/6.4/html/users_guide/faster.html Increasing the heap and allocation area size (with -H, -M and -A) helped improved my runtimes considerably (by preventing all of my execution time from being sucked up by the garbage collector), but I have some questions: 1. What "goes wrong" with mutable data and generational garbage collection to make this sort of workaround necessary? The issue surprised me because I thought there was plenty of satisfied experience with generational gc for languages with many more destructive updates (e.g. Java) than Haskell. Is there some optimization that the ghc runtime is not implementing? 2. If there is a known fix for this issue, what would it involve (and, if there are any guesses, how much work might it be)? 3. What is the best workaround for this issue if you *don't* know the maximum amount of memory available for your program? Would be it be best to fall back copying collection if you want your program to consume and release memory "as needed" or is there a cleverer trick? Thanks, - Ravi

5 5

Re: 6.2.1 for glibc-2.4
by Simon Marlow 20 Apr '06

20 Apr '06

[ replaying on glasgow-haskell-users(a)haskell.org ] Paul A. Steckler wrote: > [Apologies for the cross-post from Haskell Cafe, but I got no responses > there.] > > I need a Linux ghc 6.2.1 built with glibc-2.4. The existing 6.2.1 RPM, > built with glibc-2.3, works mostly OK, but with some programs, the > generated executables barf and die on startup. > > Any suggestions on how to create such a beast? > > I've tried using ghc 6.4.1, for which there's a Fedora 5 RPM, to build > 6.2.1 from source, but all sorts of compile errors occur. It's not always possible to build old releases using newer releases, I wouldn't be surprised if this didn't work. Why do you need 6.2.1 specifically? Perhaps you can fix your client code and use 6.4.1 (or 6.4.2) instead? Cheers, Simon

2 1

getrlimit -M
by John Meacham 19 Apr '06

19 Apr '06

perhaps if -M is not otherwise set, 'getrlimit(RLIMIT_AS,..)' could be called and the maximum heap size set to just under that, since it is the point that the OS will forcefully kill the program anyway. John -- John Meacham - ⑆repetae.net⑆john⑈

3 3

GHC 6.5 error? Illegal polymorphic or qualified type
by Rene de Visser 18 Apr '06

18 Apr '06

Hello, I tried to compile HAppS using the latest GHC snapshot (in compiles fine with 6.41). I for example get the error /home/rene/repos/HAppS/src/HAppS/MACID/Var.hs:23:0: Illegal polymorphic or qualified type: forall state event. Ev state event (ref t) In the type signature for `newEmptyRef': newEmptyRef :: (Monoid t, Ref ref) => AnyEv (ref t) Note that AnyEv is defined as type AnyEv a = forall state event. Ev state event a This should be OK shouldn't it? At least in works in 6.41 and everythis is quantified. Exactly what does the error message Illegal polymorphic or qualified type mean? Rene.

3 2

build log
by David Roundy 18 Apr '06

18 Apr '06

Hi all. Here's a build log from my bootstrap failure. -- David Roundy http://www.darcs.net

1 0

trouble bootstrapping ghc head
by David Roundy 18 Apr '06

18 Apr '06

Hi all, I'm getting the following error when bootstrapping the ghc head darcs repository: /usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "hschooks.h"' -i../compat -ignore-package Cabal -c ../compat/Distribution/Version.hs -o stage1/../compat/Distribution/Version.o -ohi stage1/../compat/Distribution/Version.hi ghc-6.4: error: directory portion of "stage1/../compat/Distribution/Version.o" does not exist (used with "-o" option.) <<ghc: 14201992 bytes, 3 GCs, 92408/92408 avg/max bytes residency (1 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.08 MUT (0.15 elapsed), 0.04 GC (0.04 elapsed) :ghc>> make[1]: *** [stage1/../compat/Distribution/Version.o] Error 1 make: *** [stage1] Error 1 I suspect this is related to the recent directory reorganization, but can't see whether it's something that I'm doing wrong or a makefile bug. -- David Roundy http://www.darcs.net

2 1

trouble bootstrapping ghc head
by David Roundy 18 Apr '06

18 Apr '06

Hi all, I'm getting the following error when bootstrapping the ghc head darcs repository: /usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "hschooks.h"' -i../compat -ignore-package Cabal -c ../compat/Distribution/Version.hs -o stage1/../compat/Distribution/Version.o -ohi stage1/../compat/Distribution/Version.hi ghc-6.4: error: directory portion of "stage1/../compat/Distribution/Version.o" does not exist (used with "-o" option.) <<ghc: 14201992 bytes, 3 GCs, 92408/92408 avg/max bytes residency (1 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.08 MUT (0.15 elapsed), 0.04 GC (0.04 elapsed) :ghc>> make[1]: *** [stage1/../compat/Distribution/Version.o] Error 1 make: *** [stage1] Error 1 I suspect this is related to the recent directory reorganization, but can't see whether it's something that I'm doing wrong or a makefile bug. -- David Roundy

1 0

RE: FFI Bug - Finalizer always called with NULL pointer?
by Simon Peyton-Jones 15 Apr '06

15 Apr '06

Would you like to add to the GHC FAQ, or even start a "Hints about using the FFI" page? http://haskell.org/haskellwiki/GHC:Documentation (The section at the bottom called "collaborative documentation" is the place.) Hard-won experience like this should be captured. GHC's documentation is a Wiki specifically so that you can record it. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Brian Hulley | Sent: 08 April 2006 10:35 | To: Brian Hulley; glasgow-haskell-users(a)haskell.org | Subject: Re: FFI Bug - Finalizer always called with NULL pointer? | | > [Helpful off-list suggestion to look at FFI spec for & more closely] | | Thanks. I'd read it several times before but hadn't understood the | difference between a function and the address of a function and so thought | '&' was optional, as it is in C for functions: | | void foo(); | | typedef void (*Fun)(); | | Fun a = &foo; | Fun b = foo; // same as above (in VC7) | | However I see now that in the Haskell FFI my original declaration, without | the &, was declaring duma_releaseFont to be a function taking no args and | returning a FunPtr, whereas with the &, I am declaring duma_releaseFont to | be the FunPtr itself. The '&' is needed because otherwise there would be no | way to distinguish the wrapping of a C function in a FunPtr and a C function | returning a FunPtr. | | So in a way it is "obvious" but only when it is realised that '&' actually | means something in Haskell FFI even though it is irrelevant (when taking | about functions) in C. | | Therefore there is no bug anywhere. It is just that FFI has a high learning | curve since it rests on extremely subtle but vital distinctions foreign to a | C programmer... :-) | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1