April 2009 - Glasgow-haskell-users

Re: [Haskell-cafe] HPong-0.1.2 fails to compile in Debian ghc 6.10.1
by John Goerzen 24 Apr '09

24 Apr '09

Ahn, Ki Yung wrote: > I don't know the exact reason but this should not fail since I have > Debian packaged ghc 6.10.1 and OpenGL-2.2.1.1 on my system. > > I think this is because the filename of the OpenGL shared library is > /usr/lib/libGL.so.1 rather than libGL.so. This is why we have two No. Do not manually create the symlink. It sounds like you don't have the -dev packages for OpenGL installed. You should install them and then you should be OK.

3 2

No "last core parallel slowdown" on OS X
by Dave Bayer 22 Apr '09

22 Apr '09

I'm a huge fan of the recent paper http://ghcmutterings.wordpress.com/2009/03/03/new-paper-runtime-support-for… which put me over the top to get started writing parallel code in Haskell. Parallel code is now integral to my and my Ph.D. students' research. For example, we recently checked an assertion for the roughly 69 billion atomic lattices on six atoms, in a day rather than a week, using perhaps 6 lines of parallel code in otherwise sequential code. When you're anxiously waiting for the answer, a day is a lot better than a week. (The enumeration itself is down to two hours on 7 cores, which astounds me. I see no reason to ever use another language.) In that paper, they routinely benchmark N-1 cores on an N core Linux box, because of a noticeable falloff using the last core, which can do more harm than good. I had confirmed this on my four core Linux box, but was puzzled that my two core MacBook showed no such falloff. Hey, two cores isn't representative of many cores, cache issues yada yada, so I waited. I just got an EFi-X "boot processor" (efi-x.com) working on a nearly identical quad core box that I built, and I tested the same computations with OS X. For my test case, there's a mild cost to moving to parallel at all, but... Compared to 2 cores, using 3, 4 cores on a four core Linux box gives speedups of 1.37x, 1.38x Compared to 2 cores, using 3, 4 cores on an equivalent four core box running OS X gives speedups of 1.45x, 1.9x Here 1.5x, 2.0x is ideal, so I'm thrilled. If we can't shame Linux into fixing this, I'm never looking back. How true is this for other parallel languages? Haskell alone is perhaps too fringe to cause a Linux scandal over this, even if it should... The EFi-X boot processor itself is rather expensive ($240 now), and there's sticking to a specific hardware compatibility list, and I needed to update my motherboard BIOS and the EFi-X firmware, but no other fiddling for me. These boxes are just compute servers for me, I would have been ok returning to Linux, but not if it means giving up a core. People worry about compatibility, "I sensed a softness in the surround sound in game X...", but for me the above numbers put all this in perspective. Another way to put this, especially for those who don't have a strong preference for building their own machines, and can't wait for Linux to get its act together: If you're serious about parallel Haskell, buy a Mac Pro.

7 14

Using FFI for .NET
by Guilherme Oliveira 22 Apr '09

22 Apr '09

Hi guys, I'm new to haskell and I'm trying to make some calls to static methods of the Microsoft .NET framework with GHC 6.10.2 but I'm getting the follwoing error: GHC error in desugarer lookup in main:Main: > Failed to load interface for `GHC.Dotnet': > There are files missing in the `base' package, > try running 'ghc-pkg check'. > Use -v to see a list of the files searched for. > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.2 for i386-unknown-mingw32): > initDs IOEnv failure > My haskell code is this: {-# LANGUAGE ForeignFunctionInterface #-} module Main where import Prelude import Foreign foreign import dotnet "static foo" foo :: Int -> Int main = do print (foo 5) To build the code above I'm doing like this: ghc -fvia-C Main.hs Am I forgeting something? Does this version of GHC supports FFI for .NET? Regards, Guilherme Oliveira MSc Student, UFPE - Brazil

2 1

my last letter
by Serge D. Mechveliani 21 Apr '09

21 Apr '09

Dear GHC team, I withdraw my last bug report. It was about processing a long list on a 64 bit machine оn GHC-6.10.2. First, I cannot reproduce (?) this bug report invitation from GHC on using +RTS -M4000m Second, I have found that the process interruption only occurs when this test program runs out of RAM. And personally, I would rather use "+RTS -M15000m -RTS" and not to consider at all the system effects after the RAM overflow. Third, I apply now a more clear example, whith [Int] instead of [Integer]: --------------------------------------------------------- import List (genericReplicate) main = putStr (shows res "\n") where e = -- 22, 23 ... list = genericReplicate (2^e) 1 :: [Int] rList = reverse list res = myMin $ zipWith (+) list rList myMin [] = error "\nmyMin []\n" myMin [x] = x myMin (x: y: xs) = if x > y then myMin (y: xs) else myMin (x: xs) ------------------------------------------------------ ghc -O --make Test64 ./Test64 +RTS -M800m -RTS -- for 1 Gb 32 bit machine ./Test64 +RTS -M12000m -RTS -- for 16 Gb 64 bit machine The last possible e for the small machine (800 Mb) occurs 24, for the big machine (12000 Mb) occurs 27 -- which looks reasonable. The timing also looks reasonable. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Parallel performance drops off a cliff
by Neil Mitchell 21 Apr '09

21 Apr '09

Hi, Using one benchmark I have, which doesn't create any threads, I have: $ benchmark +RTS -Nx x time (Seconds) 1 2 2 2 3 2 4 3 5 3 6 3 7 3 8 aborted after 2 minutes This is using GHC 6.10.2 on Windows XP, 2 processors. Is this a known bug, or should I try and replicate it? (benchmark is fairly big and very dependent on internal things, but I suspect the dramatic performance slowdown is unlikely to be related to these bits). Thanks Neil

3 4

failure implementing :next command in ghci
by Peter Hercek 21 Apr '09

21 Apr '09

Hi, So I wanted to give implementing :next ghci debugger command a shot. It looked easy and I could use it. Moreover it would give me an easy way to implement dynamic stack in ghci (using similar approach as used for trace) ... well if I would feel like that since I was a bit discouraged about it. The problem is I failed miserably. I still think it is easy to do. I just do not know how to create correct arguments for rts_breakpoint_io_action and I have given up finding up myself for now. The proposed meaning for :next Lets mark dynamic stack size at a breakpoint (at which we issue :next) as breakStackSize and its selected expression as breakSpan. Then :next would single step till any of these is true: 1) current dynamic stack size is smaller than breakStackSize 2) current dynamic stack size is equal to breakStackSize and the current selected expression is not a subset of breakSpan I hope the above would make good sense but I do not really know since maybe rts does some funny things with stack sometimes. If you think the proposed behavior is garbage let me know why so that I do not waste more time with this :) Ok, lets get back to why I failed. I think anybody who knows rts well could probably tell me what's wrong in few minutes. The patch representing my attempt is attached. It is done against the latest ghc (head branch). I want to add stack size as the last argument of rts_breakpoint_io_action so its signature would change from: Bool -> BreakInfo -> HValue -> IO () to: Bool -> BreakInfo -> HValue -> Int -> IO () Since dynamic stack is continuous I can find out stack size easily. I did not implemented this yet, as well I did not implement this at all for exceptions. The only thing I cared for now is passing one more integer to rts_breakpoint_io_action. The argument contains only zero now but that should be enough to see if I can add one more argument. I tested it by loading this source code to ghci: f :: Int -> Int f x = x + 1 a = f 1 ... then I used ":break f" and ":force a" in ghci to see whether I can pass the new argument correctly. This test works since I added printing of the last argument (the wanna be stack size) in noBreakAction :: Bool -> BreakInfo -> HValue -> Int -> IO () noBreakAction False _ _ x = putStrLn $ "*** Ignoring breakpoint " ++ show x noBreakAction True _ _ _ = return () -- exception: just continue The noBreakAction implementation is just a test for now. Unfortunately when I force the last argument it crashes. I think it is because I do not create the closure for it correctly in the code for bci_BRK_FUN in rts/Interpreter.c. Can somebody tell me what is wrong there or where to find more information about how to fill in the stack with rts_breakpoint_io_action arguments correctly? Also, any information somewhere about where to use allocate and where to use allocateLocal? I was surprised a bit that interpretBCO uses allocate much but no allocateLocal which is supposed to be quicker for a single thread. I skimmed all of ghc commentary and read the pages which looked related carefully but either it is not there or I missed it :-( Thanks, Peter.

2 5

trouble compiling 6.8.3 using 6.8.3
by Jason Pepas 20 Apr '09

20 Apr '09

Hi Guys, I'm trying to rebuild ghc 6.8.3 (the previous version was built without readline linked in), and I'm running into a compilation issue. build error: /lusr/bin/ghc -#include cutils.h -DSTAGE=1 -package-name ghc-6.10.1 -hide-all-packages -no-user-package-conf -package-conf /v/filer4b/cvsbuild/CVSBUILD/ghc-6.8.3-linux-i686/ghc/libraries/bootstrapping.conf -i -idist-stage1/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise -idist-stage1/build/autogen -Idist-stage1/build/autogen -Idist-stage1/build -Istage1 -I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils -optP-include -optPdist-stage1/build/autogen/cabal_macros.h -odir dist-stage1/build -hidir dist-stage1/build -stubdir dist-stage1/build -package Cabal-1.6.0.1 -package array-0.1.0.0 -package base-3.0.2.0 -package bytestring-0.9.0.1.1 -package containers-0.1.0.2 -package directory-1.0.0.1 -package extensible-exceptions-0.1.0.0 -package filepath-1.1.0.1 -package haskell98-1.0.1.0 -package hpc-0.5.0.2 -package old-time-1.0.0.0 -package process-1.0.0.1 -package unix-2.3.0.1 -O -Wall -fno-warn-name-shadowing -fno-warn-orphans -XPatternSignatures -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -idist-stage1/build -H32m -O -Rghc-timing -c types/Unify.lhs -o dist-stage1/build/Unify.o -ohi dist-stage1/build/Unify.hi parser/Lexer.x:1652:17: Not in scope: data constructor `SLIT' parser/Lexer.x:1653:23: Not in scope: data constructor `SLIT' <<ghc: 351226848 bytes, 20 GCs, 3982677/8409088 avg/max bytes residency (3 samples), 36M in use, 0.00 INIT (0.00 elapsed), 0.32 MUT (0.37 elapsed), 0.12 GC (0.13 elapsed) :ghc>> make[2]: *** [dist-stage1/build/Lexer.o] Error 1 make[2]: *** Waiting for unfinished jobs.... <<ghc: 236588812 bytes, 17 GCs, 4490581/8404992 avg/max bytes residency (3 samples), 36M in use, 0.00 INIT (0.00 elapsed), 0.49 MUT (0.57 elapsed), 0.15 GC (0.15 elapsed) :ghc>> make[1]: *** [build.stage.1] Error 2 make: *** [stage1] Error 1 I've hit up google and the only results which stood out were other "data constructor not in scope" messages which were due to people trying to run old haskell code using newer versions of the compiler, but I doubt that's the case here as I am using the same version of the compiler as both host and target. Any ideas? -jason

2 4

Segfault in RSAGL with +RTS -G4
by Christopher Lane Hinson 20 Apr '09

20 Apr '09

I regret that I don't have a simpler failure case, but I'm just going to post this and please advise me. I don't see how to get debugging symbols to work to even look at a core dump. Usually I get a segfault, but sometimes I get this: _rsagl_modelview: internal error: evacuate: strange closure type 2053 (GHC version 6.10.1 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted This program uses ffi, but in this checkin I've disabled RSAGL's ffi except the GLUT+OpenGL bindings. So it's OpenGL or ghc. The key to getting this error is the -G flag. -G4 or -G3 segfaults. Steps to replicate: git clone http://www.downstairspeople.org/git/rsagl.git cd rsagl/ git checkout possible_rts_bug_g4 cabal configure && cabal build ./dist/build/_rsagl_modelview/_rsagl_modelview +RTS -G4 -RTS <-- just sit and wait, it should display an animation briefly and then segfault. Friendly, --Lane

2 1

ghc-pkg check problem in 6.10.2
by Simon Marlow 20 Apr '09

20 Apr '09

I just noticed that the new 'ghc-pkg check' feature exposes a silly mistake in the definition of the rts package that we ship with GHC 6.10.2: $ ghc-pkg check There are problems in package rts-1.0: include-dirs: PAPI_INCLUDE_DIR doesn't exist or isn't a directory ... To fix it, issue this command: $ ghc-pkg describe rts | sed 's/PAPI_INCLUDE_DIR//' | ghc-pkg update - and now "ghc-pkg check" should give no errors: $ ghc-pkg check $ (Except on Windows, where there also seems to be a problem with the Haddock package. Haddock itself is ok, but the Haddock library has some problems with its registration.) Cheers, Simon

2 2

Re: Problem installing GHC 6.10.2 on Debian Etch
by Daniel van den Eijkel 16 Apr '09

16 Apr '09

That helped. $ aptitude remove ghc did not remove or install any packages, but now ghc --version says 6.10.2 on the other hand, ghc 6.8.2 is still on the system dpkg -l says ghc6 6.8.2dfsg1-1 GHC - the Glasgow Haskell Compilation system ghc6-doc 6.8.2dfsg1-1 Documentation for the Glasgow Haskell Compilation system ghc6-libsrc 6.6-3 Library Sources of GHC, the Glasgow Haskell Compilation system ghc6-prof 6.8.2dfsg1-1 Profiling libraries for the Glasgow Haskell Compilation system $ ls -l /usr/bin/ghc* /usr/bin/ghc -> /etc/alternatives/ghc /usr/bin/ghc6 -> ../lib/ghc-6.8.2/bin/ghc /usr/bin/ghc-6.8.2 -> ../lib/ghc-6.8.2/bin/ghc-6.8.2 /usr/bin/ghci -> /etc/alternatives/ghci /usr/bin/ghci6 -> ../lib/ghc-6.8.2/bin/ghci /usr/bin/ghci-6.8.2 -> ../lib/ghc-6.8.2/bin/ghci-6.8.2 /usr/bin/ghc-pkg -> /etc/alternatives/ghc-pkg /usr/bin/ghc-pkg6 -> ../lib/ghc-6.8.2/bin/ghc-pkg /usr/bin/ghc-pkg-6.8.2 -> ../lib/ghc-6.8.2/bin/ghc-pkg-6.8.2 /usr/bin/ghcprof -> /etc/alternatives/ghcprof /usr/bin/ghcprof6 -> ../lib/ghc-6.8.2/bin/ghcprof $ ls -l /etc/alternatives/ghc* /usr/bin/ghc -> /etc/alternatives/ghc /usr/bin/ghc6 -> ../lib/ghc-6.8.2/bin/ghc /usr/bin/ghc-6.8.2 -> ../lib/ghc-6.8.2/bin/ghc-6.8.2 /usr/bin/ghci -> /etc/alternatives/ghci /usr/bin/ghci6 -> ../lib/ghc-6.8.2/bin/ghci /usr/bin/ghci-6.8.2 -> ../lib/ghc-6.8.2/bin/ghci-6.8.2 /usr/bin/ghc-pkg -> /etc/alternatives/ghc-pkg /usr/bin/ghc-pkg6 -> ../lib/ghc-6.8.2/bin/ghc-pkg /usr/bin/ghc-pkg-6.8.2 -> ../lib/ghc-6.8.2/bin/ghc-pkg-6.8.2 /usr/bin/ghcprof -> /etc/alternatives/ghcprof /usr/bin/ghcprof6 -> ../lib/ghc-6.8.2/bin/ghcprof $ ls -l /usr/local/bin/ghc* /usr/local/bin/ghc -> ghc-6.10.2 /usr/local/bin/ghc-6.10.2 /usr/local/bin/ghci -> ghci-6.10.2 /usr/local/bin/ghci-6.10.2 /usr/local/bin/ghc-pkg -> ghc-pkg-6.10.2 /usr/local/bin/ghc-pkg-6.10.2 so /usr/local/bin shadows the /usr/bin directory? I am not sure if I'm going to run into trouble with this installation, so I decided to completely uninstall the old ghc6. It removed some other packages, too: g++-4.1{u} ghc6 ghc6-prof{a} haskell-utils{u} libgmp3-dev{u} libgmpxx4ldbl{u} libncurses5-dev{u} libreadline5-dev{u} libstdc++6-4.1-dev{u} After that, there was no ghc anymore except the 6.10.2 - as desired. But a hello-world-compilation failed because of missing lgmp. So I installed libgmp3-dev and libgmpxx4ldbl Now it seems to work again, but I expect to run in trouble again. I'll keep you up-to-date. Thanks, Daniel Karel Gardas schrieb: > What does happen if you uninstall ghc-6.8.2 by using dpkg/apt-get? IIRC > ghc is completely linked statically (haskel libs) so your 6.10.2 does > not depend on 6.8.2. > > Cheers, > Karel > > Daniel van den Eijkel wrote: > >> Thanks for the answer. >> I upgraded from Debian Etch to Lenny, and this upgraded ghc to version >> 6.8.2. Then I tried again to install ghc-6.10.2 and it worked without >> problems. >> >> But now I have 2 versions, and by default ghc-6.8 is called. Is there a >> simple way to make ghc-6.10 the default ghc? Do I have to change the >> symlinks by hand? >> >> Thanks, >> Daniel >> >> Ian Lynagh schrieb: >> >>> On Thu, Apr 16, 2009 at 02:05:24PM +0200, Daniel van den Eijkel wrote: >>> >>> >>>> I am trying to install GHC-6.10.2 on Debian Etch and I get the >>>> following error: >>>> >>>> /usr/bin/strip: /usr/local/lib/ghc-6.10.2/ghc-pkg: File format not >>>> recognized >>>> >>>> >>> IIRC, this happens if you have binutils 2.17. Upgrading should fix it. >>> >>> >>> Thanks >>> Ian >>> >>> >>> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> >> > >

1 0