- Glasgow-haskell-users

Re: problem with echo prompting in ghci (visible in emacs)
by Andrea Vezzosi 12 Nov '08

12 Nov '08

I get the same behaviour, and when I open ghci in xterm and press Ctrl-D it also echoes ^D before quitting, which is similar to the problem with haskell-mode which seems to don't like the echoing of ^J from ghci when one uses commands like C-u C-c C-t (which should copy the inferred type from the ghci buffer and insert it in the current file). I'm using the ghc package from archlinux testing repository, which is built with libedit 20080712_2.11.

2 1

Making ghc utilize multiple cpus ?
by Marc Weber 09 Nov '08

09 Nov '08

Hi, haskell differs from other languages that it's easy to write parallel programs. So have there been any thoughts about making the ghc compiler compile modules in parallel utilizing multiple cpus yet? Of course you can use Makefiles for that or maybe cabal can be taught to do this. But restarting ghc multiple times wastes resources.. Sincerly Marc Weber

2 1

What causes <<loop>>?
by Creighton Hogg 08 Nov '08

08 Nov '08

Hello, So I'm trying to debug an issue that is causing GHC to emit the <<loop>> warning. I was hoping to get more information about what exactly that tells me about the kind of problem, other than the obvious interpretation that I appear to be getting into some kind of infinite loop. What is GHC detecting when it emits that warning? Thanks, Creighton

4 3

Re: ghc bug?
by Jeff Polakow 07 Nov '08

07 Nov '08

Hello, > You will be even more surpised to find out that: > > bar = (fst foo, snd foo) > > is considered correct. Does this hint give you any insight? > This tells me that GHC definitely has a bug, or at at best an infelicity. -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

2 1

ghc bug?
by Jeff Polakow 07 Nov '08

07 Nov '08

Hello, This compiles fine: foo :: forall b. (b -> String, Int) foo = (const "hi", 0) bar :: (forall b. b -> String, Int) bar = (const "hi", 0) but changing the definition of bar to: bar = foo causes a type error. -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

1 0

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