April 2006 - Glasgow-haskell-users

GHC6.5 + TH + Profiling
by Einar Karttunen 24 Apr '06

24 Apr '06

Hello I am having problems combining TH and profiling with ghc-6.5.20060420. GHC seems to die when loading the object file for TH execution and failing to notice that it should load profiling symbols. The exact error is: Loading package base-1.0 ... linking ... done. Loading package template-haskell-1.0 ... linking ... done. Loading package mtl-1.0 ... linking ... done. Loading package stm-1.0 ... linking ... done. ghc-6.5.20060420: .haskell_cache/http_searchpath.org-default.map.cache//HAppS/Util/StdMain/StartStateTH.o: unknown symbol `entering_PAP' I can create a simpler example of this if needed. - Einar Karttunen

2 1

Visual Haskell
by Dmitri Pissarenko 24 Apr '06

24 Apr '06

Hello! First of all I want to thank all the people, who developed Visual Haskell. It's a big step towards functional programming in real life. I have an application in C# in Visual Studio 2005 and Visual Haskell, which seems to work only in Visual Studio 2003 (both Visual Studios are installed on my computer). Now, is it possible to write parts of the C# application in Visual Haskell? If yes, is there any downloadable tutorial about how one can use Visual Haskell in collaboration with other Microsoft languages? TIA Dmitri Pissarenko

2 1

FW: 6.4.2 build Sound/OpenAL/ALC error
by Simon Marlow 24 Apr '06

24 Apr '06

Forwarding to glasgow-haskell-users(a)haskell.org -----Original Message----- From: mailman-bounces(a)haskell.org [mailto:mailman-bounces@haskell.org] On Behalf Of Erik J Pearson Sent: 24 April 2006 06:21 To: glasgow-haskell-users-owner(a)haskell.org Subject: 6.4.2 build Sound/OpenAL/ALC error While building 6.4.2 on SuSE 10.0 with 6.4.1, I encountered this error. Is this a known issue? ../../ghc/compiler/ghc-inplace -H16m -O -Wall -fffi -Iinclude '-#include "HsOpenAL.h"' -cpp -DCALLCONV=ccall -ignore-package OpenAL -O -Rghc-timing -fgenerics -package base -package OpenGL -fgenerics -split-objs -c Sound/OpenAL/ALC/Capture.hs -o Sound/OpenAL/ALC/Capture.o -ohi Sound/OpenAL/ALC/Capture.hi Sound/OpenAL/ALC/Capture.hs:85:3: Couldn't match `NumSamples' against `Sound.OpenAL.Config.ALCint' Expected type: GettableStateVar NumSamples Inferred type: GettableStateVar Sound.OpenAL.Config.ALCint In the expression: makeGettableStateVar $ (getInteger (Just device) CaptureSamples) In the definition of `captureNumSamples': captureNumSamples device = makeGettableStateVar $ (getInteger (Just device) CaptureSamples) <<ghc: 31117576 bytes, 10 GCs, 1478944/2861380 avg/max bytes residency (2 samples), 17M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (0.26 elapsed), 0.13 GC (0.13 elapsed) :ghc>> make[2]: *** [Sound/OpenAL/ALC/Capture.o] Error 1 Thanks for all the great work. --erikp--

1 0

Re: GHC 6.4.2 release candidates
by Simon Marlow 23 Apr '06

23 Apr '06

Duncan Coutts wrote: > On Tue, 2006-03-28 at 12:34 +0100, Simon Marlow wrote: > >>Hi Folks, >> >>We're finally in release-candidate mode for 6.4.2. Please grab a >>snapshot and try it out: >> >>http://www.haskell.org/ghc/dist/stable/dist/ >> >>(scroll to the bottom for the latest). The available builds are: >>x86_64-unknown-linux (Fedora Core 5), i386-unknown-linux (glibc 2.3 >>era), and Windows (i386-unknown-mingw32). >> >>There's a source snapshot if you want to build yourself - please try >>this if you can, we need to make sure the source bundle builds cleanly. > > > One thing that Don, Ian and I were discussing was having a tarball of > the testsuite and nofib performance suite to go along with the official > 6.4.2 release. This would make it easier for us to be consistent. Having > the testsuite go with the ghc release will mean we can be sure about > which tests we expect to fail on x86/amd64 and we can use that as a > comparison for the other arch ports. I've put the testsuite bundle here: http://haskell.org/ghc/dist/ghc-testsuite-6.4.2.tar.gz There are zero unexpected failures on x86/x86_64 on Linux. I think there may be a few unexpected failures on Windows, but I've checked them and they're not fatal. I'll probably update nofib and make a bundle of that too. There are currently a few bogus failures due to floating point wibbles. > If we could get a tarball of the testsuite out before the release then > we can send in our results for various arches and that could be included > into the know failures files for the testsuite that goes official > release. It'd give us a better sense of the state of things on each > arch. Perhaps we could record testsuite results for different arches on > the ghc wiki somewhere. Sure, that's a good idea. I've left it a bit late to make any changes to 6.4.2 based on anything you find, but it'll still be useful to record the results for comparison with future versions. Cheers, Simon

2 1

Building ghc stages
by Marc Weber 22 Apr '06

22 Apr '06

I've tried building ghc with make all; make install But when compiling one of my programs I get GHC stage restriction: `view' is used in a top-level splice, and must be imported, not defined locally What did I do wrong? Marc

3 4

'while' loop on mutable arrays causes stack overflow
by Gunnar Kedenburg 20 Apr '06

20 Apr '06

Hello, a friend and I were recently experimenting with mutable arrays. We tried to implement a simple dot product on STUArrays using a 'while' loop. Unfortunately, every implementation we produced caused a stack overflow. Switching to other implementations of 'while' or to IOUArrays did not help us. We were using ghc-6.4.1 on Linux x86, with gcc 3.3.6. It runs perfectly, and is actually quite fast, when we increase the stack space. :) > import Control.Monad.ST > import Data.STRef > import Data.Array.ST > import Control.Monad.Fix > import Control.Monad > > while :: STRef s Bool -> ST s () -> ST s () > while b c = readSTRef b >>= \v -> when v (c >> while b c) > > dot :: STUArray s Int Double -> STUArray s Int Double -> ST s Double > dot x y = do > let (l,r) = bounds x > a <- newSTRef 0.0 > e <- newSTRef l > b <- newSTRef True > while b (do > ev <- readSTRef e > av <- readSTRef a > xe <- readArray x ev > ye <- readArray y ev > writeSTRef b (ev<r) > writeSTRef e (ev+1) > writeSTRef a (av+xe*ye)) > readSTRef a > > main = do > let d = runST (do > x <- newArray (1, 1000000) 1.0 > y <- newArray (1, 1000000) 2.0 > dot x y) > putStrLn $ show d Unfortunately, I did not keep every 'while' implementation we tried, just this one: > while b c = fix (\d -> readSTRef b >>= > (\v -> if v then c >> d else return ())) We also changed the 'dot' code to use a 'for' loop instead, using IOUArrays in this case: > for :: Int -> IO () -> IO () > for 0 c = return () > for n c = c >> for (n-1) c Needless to say, it did not help. Any hints why the stack overflows would be greatly appreciated. Thanks, Gunnar.

3 5

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 19 Apr '06

19 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