- Glasgow-haskell-users

Static library to redefine entrypoint
by Philip K.F. Hölzenspies 25 Apr '09

25 Apr '09

Dear GHCers, I am trying to write a wrapper library for lab work to give to students. My problem is, that the libraries I use require initialization that I really want to hide from our students. The wrapper I'm writing is compiled to a static library and installed with cabal, so students can just "ghc --make" or "ghci" their sources. Here comes the problem: I want to define main and let students just define labMain as an entry point to their program. How can I have my library use "labMain" without a definition? Keep in mind that I want to give them a cabalized library that they can just link to, so I can't give them a template file that they fill and compile together with my code. Is it at all possible to have "external" functions and letting the linker sort stuff out? Regards, Philip

3 3

writeFile/readFile on multiple threads leads to error
by Neil Mitchell 24 Apr '09

24 Apr '09

Hi, I've got a multi-threaded application which occasionally generates failures in openFile. I haven't been able to reproduce the errors reliably, the code is way too large to send over, and any small attempts at invoking the same problem don't seem to work. Despite the uselessness of the bug report, I thought I'd share what I've seen and how I fixed it. I have many threads, which read and write files. Every so often one thread will write a file, then another thread will read the same file - but fail during the open call. There are locks to ensure that the write call finishes before the read call begins. I modified the code to give: do print ("READ START",x) ; res <- readFile x ; print ("READ STOP",x) ; return res do print ("WRITE START",x); writeFile x src ; print ("WRITE STOP",x) I then get on the console: WRITE START foo WRITE STOP foo READ START foo openFile doesn't have permission to open foo. The writeFile/readFile are happening in different threads, and they usually succeed - but not always. The bug seems to go away when I add performGC just after writeFile. My guess is that something in the openFile/hClose pair isn't really closed until a garbage collection happens. All this is using GHC 6.10.2 on XP through Cygwin. I'm happy to supply more details if you can think of anything that will help, Thanks Neil

6 11

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