Hi!
I have a low-level function for insertion element into mutable vector. It
looks like this:
place :: (PrimMonad m) =
MV.MVector (PrimState m) (Int, t) - (Int, t) - Int - m ()
place v max@(val1,_) i = place' i
where
place' i = do
let j = i - 1
if j 0
then return ()
Hi!
You have to look outside the place function, which is strict enough. I
would look for a call to unsafeWrite that doesn't evaluate it's
argument before writing it into the vector. Perhaps you're doing
something like:
MV.unsafeWrite (i + 1, ...)
Since tuples are lazy the i + 1 will be
Ryan Ingram schrieb:
Hi Alexei, you have a ton of great points but I wanted to discuss an
issue with this one.
It's unusual that this is what you want either; since it only reduces
the state to WHNF. For example, if your state is a string, this only
evaluates enough to know whether or not
On Sat, Jan 9, 2010 at 2:23 AM, Alexei Kitaev kit...@iqi.caltech.edu wrote:
Reading the discussion related to your blog, I
realized that strict State is different in that it does not actually
force the state. But forcing can be achieved by wrapping all actions
with the following function:
Dear David,
Thank you for your comments. I understand your suggestion that a program
should contain some synchronization points where the values are
evaluated. But this is not easy. Maybe I should just practice more.
I while ago I played with the strict and lazy ST monads and was able to
achieve
Dear Haskellers,
Recently I have been looking for a programming language that would be
suitable for small scientific and recreational projects and palatable to
a picky person like me. (I do theoretical physics and some math; I do
not program very often.) Haskell and Clean look attractive from a
2) While each step is predictable, the overall behavior of a lazy
program can be rather surprising. So one must be very careful. GHC
provides two ways to control the evaluation order, seq and bang
patterns, but I am not sure which of these (if any) is the right tool.
Consider the following
Hello everyone,
I have this piece of code I've been working on, and I've been stuck on
tracking down a space leak in it for some time now. The code is
essentially a tight loop that updates a rather largish data structure
with embedded functions that are called by the driver loop. The code
On Thu, Jul 17, 2008 at 12:14 PM, Peter Gavin [EMAIL PROTECTED] wrote:
Hello everyone,
I have this piece of code I've been working on, and I've been stuck on
tracking down a space leak in it for some time now. The code is essentially
a tight loop that updates a rather largish data structure
Peter, from 500 feet, we can't see much, but your strictness might
actually be your problem depending on what largish looks like and
whether you're reading your data from disc. It's entirely possible
that your data structure updates or disc reads are head-strict and
you're evaluating or loading
On Thu, Jul 17, 2008 at 11:14 AM, Peter Gavin [EMAIL PROTECTED] wrote:
evaluated anywhere. I've used retainer profiling, and the functions that
are leaking space according to the profiler output are strict throughout.
Have you looked at the Core code generated? That might show something that
Thanks for the responses.
This is basically what I've got looks like (grossly simplified):
data Monad m = Foo m a b =
Foo
{ action :: m (Foo m a b, b)
, update :: a - Foo m a b
}
The driver loop injects new values with update, and executes action
whenever it's ready to,
Replying to myself...
Interesting. I removed all the bangs other than the obvious loop
variables, and all the uses of seq that I had inserted, and there's
still no leak.
Does anyone know why the leak would disappear when GHC is using IO other
than a generic (unspecified) monad? Is there
I'd like to hear what tips and techniques you guys have for avoiding space
leaks. I understand the basic techniques to force evaluation of closures.
What I'd like to know is how you avoid space leaks in large, long-lived,
mutable data structures. These kind of data are particularly sensitive
I've been starting to take note of discussion about space leaks in
Haskell. So far, it's not a topic that's bothered me, other than obvious
programming errors, and I've never found the need to force strict
evaluation of my Haskell programs. I find myself wondering why this is.
Your comment
In my experience, any time your program makes use of some state-like
structure which gets updated over a number of iterations, you're going
to be in trouble with space leaks.
There's a library function which summarises this nicely,
mapAccumL :: (state - x - (state, y)) - state - [x] - (state,
On Wed, Oct 06, 2004 at 12:27:35PM +1000, Ben Lippmeier wrote:
Now imagine that state is some large structure. The [x] list is a couple
of hundred elements long, and you print out some - but not all - of
the [y] elements. While the [y] list remains live, a whole collection of
half
17 matches
Mail list logo
