Andy, For the asteroids game, I just call GHC's System.Mem.performGC every frame and it seems to run ok. It's a very simple game, my 2.6Ghz P4 system walks all over it and the FPS counter seems to bounce around from about 150 to 300. I would imagine it's spending all it's time in the big XFillRectangle call I'm using to blank the screen, and without double buffering it flickers pretty bad. I wrote the game as a way to get some non-tree-processing experience with Haskell, and to test out a C struct marshalling FFI preprocessor I was messing with. All the graphics stuff is written using straight Xlib, called from Haskell. You're more than welcome to the code if you think you can do something with it. You can get it from my homepage at http://cs.anu.edu.au/people/Ben.Lippmeier There's also a mandelbrot set plotter, written in Haskell, which I wrote to try out various unboxing schemes. The only other (reasonably current) real-time projects i've heard of are: * The HOpenGL effort and Haskell Quake. HOpenGL seems to be somewhat active, you might like to try out some of their sample programs. I tried to get Haskell Quake to work once, but from memory they were using an ancient version of Greencard/HOpenGL for their FFI, which I couldn't get to work. The Haskell Quake home page says it hasn't been updated since 1997. * Alastair Reid's real-time computer computer vision project, FVision. http://www.reid-consulting-uk.ltd.uk/alastair/ I think they solved their Garbage Collection stall problem the same way I did, just invoked the garbage collector some fixed number of times per second / frame.. Don't know much about it, best ask him directly. * The Haskell DSP libraries http://haskelldsp.sourceforge.net/ I think its mostly an off-line, don't-care-too-much-about-runtime -performance kind of thing. I think it consists of a collection of (typically) list to list functions, so its not really designed for real time operation. However, a while back I had the idea that if you wanted to burn some CPU cycles in a real-time way, you might try piping to/from /dev/dsp with a full duplex souncard to make yourself some sort of poor-mans effect processor. Thats it. Not much code deployed out in the 'world' it seems. My PhD project is also aligned with addressing this issue. I think it's one of those catch 22 situations where no-one has written real-time programs in Haskell cause they knew it probably wouldn't work.. So when someone comes up with a new language feature which tries to solve the problem, there's no programs to try it on cause no-one's written any. Do you know of any other real-time type projects besides these? Perhaps the two of us, and who ever else is interested, should choose some real-time program (perhaps the asteroids game, or revive Haskell Quake) and spend some small, fixed amount of time per week working on it so we'll all have some application to showcase our glorious new language features with? Ben. Andrew Cheadle wrote:

Hi Ben

...

-> An astroids game I wrote for X. The state: position, velocities of ship, astroids, missiles. The [x] list: ship control data, key codes. The [y] list: a list of graphics prims which get rendered to the screen.

I wonder if you could help me out. I'm trying to investigate the practical use of my incremental collector for GHC over the standard generational collector. I'm looking for applications that have soft-real time constraints / interactive nature where garbage collector pauses are noticable. Do you know of any such applciations, did your asteroids game suffer any such problems? Although graphical programs would be great, when written in Haskell the rendering engine is usually in C so they're not usually appropriate!

Any help greatly appreciated!

Cheers

Andy