<br><br><div class="gmail_quote">On Wed, Nov 11, 2009 at 9:51 AM, Bryan O'Sullivan <span dir="ltr"><<a href="mailto:bos@serpentine.com">bos@serpentine.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><div class="gmail_quote">On Wed, Nov 11, 2009 at 7:43 AM, David Leimbach <span dir="ltr"><<a href="mailto:leimy2k@gmail.com" target="_blank">leimy2k@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>I recently ran into some serious space leak difficulties that would ultimately cause this program to crash some time after startup (my simulator is also written in Haskell, and runs a LOT faster than the real application ever could, this has enabled me to fast forward a bit the data growth issues and crash in minutes instead of days!) </div>
<div></div></blockquote></div><br></div><div>It sounds to me like you were storing a Map in a StateT. Since the usual State and StateT monads don't force the evaluation of their payload, I'm not terribly surprised that such a leak should arise.</div>
</blockquote><div><br></div><div>That's exactly what was happening. The system was being far too lazy (by choices I made but didn't fully understand).</div><div><br></div><div>By pulling the Map out of the state, and pushing it back into the state, as the definition of my looping, things got a lot better.</div>
<div><br></div><div>I didn't see another *easy* way to force the state to be evaluated, except by doing IO on intermediate values. seq will only evaluate strictly if it's just underneath something else that's already been evaluated :-). The runtime doesn't look for "seq"s to force evaluation on.</div>
<div><br></div><div>I figured I was better off just creating a dependency in the evaluation, near the outermost portion of the program (the loop) that would cause a strict evaluation, and so far I was right :-)</div><div>
<br></div><div>Program behaves very well now, and responds much better too.</div><div><br></div><div>Dave</div><div><br></div></div><br>