November 2008 - Glasgow-haskell-users

How to getCh on MS Windows command line?
by Ahn, Ki Yung 12 Nov '08

12 Nov '08

What I mean by getCh is the non-buffered non-echoed version of getChar, which Hugs used to provided as an extension but not any more. Is there any way to have a non-buffered non-echoed single character input function on MS Windows command line using only the libraries in the MS Windows distribution packages of either GHC or Hugs? The reason to why this is important for me is because I am translating Graham Hutton's "Programming in Haskell" into Korean (soon to be published), which illustrates interactive programming with the example of a calculator that responds instantly for every keystroke of numbers and arithmetic operations running on text mode. It is very important to consider the readers who only have access to MS Windows systems, because Korean OS market share is completely skewed towards MS Windows for very embarrassing reasons that I do not even want to mention. And, isn't GHC developed in MSR anyway? :-) I remember that this is an old problem for both of the two most widely used Haskell implementation, Hugs and GHC. In ghc 6.8 getChar had a bit strange behavior. As far as I remember it always worked as if it were NoBuffering. Fortunately, in the recently released ghc 6.10, this has been fixed. We now actually have to set the buffering mode to NoBuffering with hSetBufferring to get the non-buffered behavior of getChar. But, it still isn't working on MS Windows. In Hugs, hSetBuffering neither works on Unix terminal nor on MS Windows command line. Surprisingly, it works in WinHugs. However, I cannot use WinHugs for my purpose because the interactive calculator example in the book also uses beep characters and ANSI codes which do not work in WinHugs. Thanks for any hacks or suggestions, -- Ahn, Ki Yung

5 8

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