How do I avoid runaway memory/cpu usage in Helm/Elerea (Haskell FRP)?

Question

I'm dipping my toes in FRP, and I've thrown together a basic "hello world" style app with Helm (based on the example here):

import FRP.Helm
import qualified FRP.Helm.Window as Window
import qualified FRP.Helm.Keyboard as Keyboard
import FRP.Elerea.Simple

data SpriteState = SpriteState {mx::Double, my::Double}

inputSignal::SignalGen (Signal (Double, Double))
inputSignal = lift toFrac Keyboard.arrows
  where toFrac (dx, dy) = (realToFrac dx, realToFrac dy)

spriteSignal::SignalGen (Signal SpriteState)
spriteSignal = foldp newState initialState inputSignal
  where
    initialState = SpriteState {mx = 0, my = 200}
    newState (dx, dy) state = state {mx = x', my = y'}
      where x' = mx state + dx
            y' = my state + dy

spriteForm::SpriteState -> Form
spriteForm state = move (mx state, my state) img
  where img = filled blue $ square 64

render::SpriteState -> (Int, Int) -> Element
render spriteState (w, h) = centeredCollage w h $ [spriteForm spriteState]

main = do
  engine <- startup defaultConfig
  run engine $ render <~ spriteSignal ~~ (Window.dimensions engine)

The program works, but cpu and memory usage quickly climb, even without user input, until it crashes.

I suspect that foldp call is accumulating state and never letting it go. Should I be using some other method to compute the current state (I don't see a foldp'), or do I need to be careful to force evaluation somewhere, or something else entirely?

Using ghc 7.8.2 and helm 0.6.0.

I think it's unlikely that `foldp` is accumulating memory. The Sprite State will be fully evaluated at every step because that information is necessary to render the image. In fact, the GHC runtime doesn't seem to be using that much memory at all (try running with `-s`). I suspect it's a bug with Helm not freeing some SDL-allocated data. — John L, Jul 10 '14 at 00:38

How do I avoid runaway memory/cpu usage in Helm/Elerea (Haskell FRP)?

0 Answers0