- Glasgow-haskell-users

GHC blog
by Simon Marlow 07 Nov '08

07 Nov '08

I finally got around to creating a GHC blog: http://ghcmutterings.wordpress.com/ This is for all things related to GHC, particularly people working on GHC to blog about what they're up to. If you want a write-bit, sign up for a wordpress account if you don't already have one (http://wordpress.com/) tell me your account name, and blog away! I've asked the planet.haskell.org admins to add us, so we should be on the planet soon. Cheers, Simon

2 1

trouble compiling OpenGL package with ghc 6.10.1 (undefined GLUT_BITMAP_8_BY_13 etc)
by Conal Elliott 06 Nov '08

06 Nov '08

While building the GLUT package (GLUT-2.1.1.2) with ghc 6.10.1, I get the following errors. I recently compiled this same version successfully in ghc-6.11.20081103. Any idea what's gone wrong? [20 of 21] Compiling Graphics.UI.GLUT.Begin ( Graphics/UI/GLUT/Begin.hs, dist/build/Graphics/UI/GLUT/Begin.o ) [21 of 21] Compiling Graphics.UI.GLUT ( Graphics/UI/GLUT.hs, dist/build/Graphics/UI/GLUT.o ) cbits/HsGLUT.c: In function `hs_GLUT_marshalBitmapFont': cbits/HsGLUT.c:26:0: error: `GLUT_BITMAP_8_BY_13' undeclared (first use in this function) cbits/HsGLUT.c:26:0: error: (Each undeclared identifier is reported only once cbits/HsGLUT.c:26:0: error: for each function it appears in.) cbits/HsGLUT.c:27:0: error: `GLUT_BITMAP_9_BY_15' undeclared (first use in this function) cbits/HsGLUT.c:28:0: error: `GLUT_BITMAP_TIMES_ROMAN_10' undeclared (first use in this function) cbits/HsGLUT.c:29:0: error: `GLUT_BITMAP_TIMES_ROMAN_24' undeclared (first use in this function) cbits/HsGLUT.c:30:0: error: `GLUT_BITMAP_HELVETICA_10' undeclared (first use in this function) cbits/HsGLUT.c:31:0: error: `GLUT_BITMAP_HELVETICA_12' undeclared (first use in this function) cbits/HsGLUT.c:32:0: error: `GLUT_BITMAP_HELVETICA_18' undeclared (first use in this function) cbits/HsGLUT.c: In function `hs_GLUT_marshalStrokeFont': cbits/HsGLUT.c:41:0: error: `GLUT_STROKE_ROMAN' undeclared (first use in this function) cbits/HsGLUT.c:42:0: error: `GLUT_STROKE_MONO_ROMAN' undeclared (first use in this function)

1 1

Re: [Haskell-cafe] ghc-6.11 + OpenGL/GLUT crashes on WinXP
by David Sankel 06 Nov '08

06 Nov '08

With ghc 6.10.1, the patches aren't necessary for the lasted releases of the bindings. I've put a walkthrough on my blog for the process of getting `freeglut+GLUT binding+GL binding+ghc 6.10.1` up and running. http://netsuperbrain.com/blog/ David On Tue, Oct 28, 2008 at 10:48 AM, David Sankel <camior(a)gmail.com> wrote: > My setup worked: > > - Windows XP. > - ghc-6.11.20081024 > - freeglut 2.4.0 > - darcs version of GLUT (with patched glutGetProcAddress [attached]) > - darcs version of OpenGL > > Getting freeglut going with ghc on windows is a bit involved. I could write > a walkthrough if there's enough interest. > > David > > 2008/10/25 Conal Elliott <conal(a)conal.net> > >> I'm getting crashes from ghc-6.10.0.20081007 and ghc-6.11.20081024 when >> doing a very simple GLUT program (below) with OpenGL-2.2.1.1 and >> GLUT-2.1.1.2 (the latest from Hackage), running on WinXP. It works fine on >> ghc-6.9.20080622 . >> >> I'd appreciate hearing about other attempts with these versions on Windows >> systems. >> >> Thanks, - Conal >> >> >> import Graphics.UI.GLUT >> >> main :: IO () >> main = do putStrLn "Initializing" >> getArgsAndInitialize >> return () >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >>

1 0

No atomic read on MVar?
by Philip K.F. Hölzenspies 06 Nov '08

06 Nov '08

Dear GHCers, I ran face first into an assumption I had made on MVar operations (in Control.Concurrent); I had assumed there to be an atomic read (i.e. non-destructive read, as opposed to destructive consume/take). The following program illustrates what I had in mind. testAtomic :: IO () testAtomic = do var <- newMVar 0 putStrLn("Fork") forkIO (putMVar var 1 >> putStrLn "X") yield r1 <- readMVar var putStrLn("1") r2 <- takeMVar var putStrLn("2") r3 <- takeMVar var putStrLn("Result: " ++ show [r1,r2,r3]) If readMVar had been atomic, the result would be program termination with a result of [0,0,1] being output. However, readMVar simply combines takeMVar and putMVar, so the reading of r1 blocks after the takeMVar, because upon taking the MVar, the blocked thread wakes up, puts 1 in var and prints X. readMVar does not terminate for r1 (i.e. "1" is never printed). I have now implemented my variable as a pair of MVars, one of which serves as a lock on the other. Both for performance reasons and for deadlock analysis, I would really like an atomic read on MVars, though. Does it exist? If not, why not? Regards, Philip

5 5

Control.Exception
by Johannes Waldmann 05 Nov '08

05 Nov '08

with 6.10, the following does not typecheck: foo `Control.Exception.catch` \ _ -> return bar Ambiguous type variable `e' in the constraint: `Control.Exception.Exception e' It is probably bad programming style anyway but what is the workaround? I found some references (in list emails) to catchAny, ignoreExceptions but these don't seem to have made it? Best regards, J.W.

9 17

Re: Control.Exception
by shelarcy 04 Nov '08

04 Nov '08

On Tue, 04 Nov 2008 19:41:58 +0900, Duncan Coutts <duncan.coutts(a)comlab.ox.ac.uk> wrote: >> >> action >> >> `catches` >> >> [ \(e :: ExitCode) -> ... >> >> , \(e :: PatternMatchFail) -> ... >> >> ] >> >> >> >> or just by using multiple catch clauses: >> >> >> >> action >> >> `catch` (\(e :: ExitCode) -> ...) >> >> `catch` (\(e :: PatternMatchFail) -> ...) >> > >> > I don't think those are equivalent. In the second case, the >> > PatternMatchFail handler scopes over the ExitCode handler. >> >> I think Duncan forgot to write parens. According to Ian's example, >> here is an equivalent code. >> >> (action >> `catch` (\(e :: ExitCode) -> ...)) >> `catch` (\(e :: PatternMatchFail) -> ...) > > David is right. If the exit code handler throws a pattern match > exception then the code behaves differently than the `catches` version. I see. I misunderstood the problem. Thanks, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/

1 0

ANNOUNCE: GHC 6.10.1 RC 1
by Ian Lynagh 03 Nov '08

03 Nov '08

We are pleased to announce that the GHC 6.10.0.20081007 snapshot is the first release candidate for GHC 6.10.1. You can download the release candidate from here: http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html This page includes: * a Windows installer * an OS X installer * bindists for amd64/Linux and ix86/Linux * the sources There is also a status page here: http://hackage.haskell.org/trac/ghc/wiki/GHC-6.10.1 where we will keep track of where the RC works, and where it is known to have problems. This is a wiki page, so please feel free to update it if you are able to add or update the information on a particular platform. Please test as much as possible; bugs are much cheaper if we find them before the release! We hope that we will be able to make the final release in around one weeks time, but of course that may slip if problems are uncovered. Thanks Ian, on behalf of the GHC team

8 15

Dilemma: DiffArray non-performance vs STArray non-readability
by Claus Reinke 03 Nov '08

03 Nov '08

I keep wanting to use DiffArray as the natural functional solution to single-threaded array use. But everytime I try, I get smacked over the head with the actual performance figures. Sometimes, even plain arrays are faster in a loop doing array updates, in spite of all the copying involved. And when copying on update dominates the runtime, using IntMap tends to be faster - the "indirections" are the wrong way round, but don't pile up, just that array lookups aren't quite constant time. But when I really need to avoid the updates, and need constant time lookup, I'm stuck: DiffArray tends to slow everything down (I vaguely recall locks and threads being at the heart of this, but I haven't checked the code recently), so my only option seems to be to transform my nice functional code into not-nice sequential code and use STArray. Is there any way out of this dilemma? What do other Ghc users use? If locks really are the issue, perhaps using STM instead of MVars in the DiffArray implementation could help. As long as my array uses are single-threaded, STM optimism might be able to avoid waiting/scheduler issues? Or am I on the wrong track? Claus PS Btw, I thought the DiffArray performance issue was ancient, but I can't find a ticket for it, nor does the haddock page for Data.Array.Diff mention this little hickup. Should I add a ticket?

4 4

cabal
by Christian Maeder 01 Nov '08

01 Nov '08

Hi, currently I've got a problem installing from hackage. using: GHC (package manager) version 6.10.0.20081019 cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library I get: Building network-2.2.0.0... Network/URI.hs:128:7: Could not find module `Data.Generics': it is a member of package base-3.0.3.0, which is hidden even with: cabal install network --constrain="base<4" (A similar problem happened with Shellac.) How is the smart selection between base-3 and base-4 going to work? Eventually, I want to install hxt-filter and Shellac-compatline. (The interface in editline changed for Shellac-editline.) Cheers Christian

4 6

file descriptors
by Johannes Waldmann 31 Oct '08

31 Oct '08

Dear all, are there any known issues with file handles/descriptors in ghc-compiled executables? My program has a lot of calls to System.Process.runInteractiveProcess and I'm running into unpredictable behaviour (sometimes the program just silently dies, sometimes it gets stuck) The handles I get correspond to file descriptors in the OS? Could there be any conflicts? (Like not enough available, or re-used to early etc.) Or perhaps you see anything that's wrong with my code here http://dfa.imn.htwk-leipzig.de/cgi-bin/cvsweb/box/src/SMT/Time.hs?rev=1.9 I'm compiling this with -threaded, but running with -N1. Of course, terminateProcess is another source of uncertainty here. (Sometimes it takes several seconds until the external process dies.) Any hints appreciated. - J.W.

3 2