Yay, that fixed it. Thanks!
On Sun, Mar 18, 2012 at 2:50 PM, Aleksey Khudyakov
wrote:
> On 18.03.2012 22:32, Clark Gaebel wrote:
>>
>> Hey list.
>>
>> I was recently fixing a space leak by dropping down to imperative
>> programming in a section of my code, when it started developing space
>> leak
On 18.03.2012 22:32, Clark Gaebel wrote:
Hey list.
I was recently fixing a space leak by dropping down to imperative
programming in a section of my code, when it started developing space
leaks of its own.
I found the problem though - it was my "for loop": http://hpaste.org/65514
Can anyone pro
Hey list.
I was recently fixing a space leak by dropping down to imperative
programming in a section of my code, when it started developing space
leaks of its own.
I found the problem though - it was my "for loop": http://hpaste.org/65514
Can anyone provide suggestions on why that stack overflow
On 21 September 2011 17:32, Felipe Almeida Lessa wrote:
> On Wed, Sep 21, 2011 at 6:04 AM, Ketil Malde wrote:
>> Tim Docker writes:
>>
>>> mapM_ applyAction sas
>>
>> Maybe you could try a lazy version of mapM? E.g., I think this would do
>> it:
>
> Another option is to use a version of
On Wed, Sep 21, 2011 at 6:04 AM, Ketil Malde wrote:
> Tim Docker writes:
>
>> mapM_ applyAction sas
>
> Maybe you could try a lazy version of mapM? E.g., I think this would do
> it:
Another option is to use a version of mapM that accumulates the result
on the heap. Maybe this would do
Tim Docker writes:
> mapM_ applyAction sas
Maybe you could try a lazy version of mapM? E.g., I think this would do
it:
import System.IO.Unsafe (unsafeInterleaveIO)
:
mapM' f = sequence' . map f
where sequence' ms = foldr k (return []) ms
k m m' = do { x <- m; xs <
On Wed, Sep 21, 2011 at 3:39 AM, Heinrich Apfelmus
wrote:
> Of course, a list of 1 million items is going to take a lot of memory,
> unless you generate it lazily. Unfortunately mapM cannot generate its
> result lazily because it has to execute all IO actions before returning the
> list of resul
On Thursday 22 September 2011, 01:00:37, Tim Docker wrote:
> I believe the error is happening in the concat because there are
> subsequent IO actions that fail to execute. ie the code is equivalent
> to:
>
> vs <- fmap concat $ mapM applyAction sas
> someOtherAction
> c
On 21/09/11 02:39, Heinrich Apfelmus wrote:
Tim Docker wrote:
I'm getting a stack overflow exception in code like this:
-- applyAction :: A -> IO [B]
vs <- fmap concat $ mapM applyAction sas
return vs
I don't get it if I change the code to this:
-
Tim Docker wrote:
I'm getting a stack overflow exception in code like this:
-- applyAction :: A -> IO [B]
vs <- fmap concat $ mapM applyAction sas
return vs
I don't get it if I change the code to this:
-- applyAction :: A -> IO [B]
I'm getting a stack overflow exception in code like this:
-- applyAction :: A -> IO [B]
vs <- fmap concat $ mapM applyAction sas
return vs
I don't get it if I change the code to this:
-- applyAction :: A -> IO [B]
mapM_ applyAc
Blimey, I didn't notice that Krzysztof came to the same conclusion a bit
earlier today, so I guess the answer is somewhere in his remark "One possible
solution is to make cell holding std gen strict.". I'd still be interested in
how to profile for this scenario, though.
-Volker
__
On Tue, 19 Apr 2011, Volker Stolz wrote:
The following three-liner creates a stack overflow (on my machine, MacOS), and
I'm a bit puzzled as to why:
import System.Random
main = do
mapM (const (getStdRandom (randomR (0, 5::Int [0..1000]
botanix:~ stolz$ ./a.out
Stack space ove
The following three-liner creates a stack overflow (on my machine, MacOS), and
I'm a bit puzzled as to why:
> import System.Random
>
> main = do
> mapM (const (getStdRandom (randomR (0, 5::Int [0..1000]
botanix:~ stolz$ ./a.out
Stack space overflow: current size 8388608 bytes.
Use
It was basically that. I was doing TransformedMatrix = TransformedMatrix *
TransformMatrrix
and should have been doing Transformed Matrix = RotatedMatrix *
TransforrmMatrix
On Thu, Nov 11, 2010 at 10:03 AM, Dmitry Astapov wrote:
> On Thu, Nov 11, 2010 at 4:58 PM, Ben Christy
> wrote:
> > I have
On Thu, Nov 11, 2010 at 4:58 PM, Ben Christy wrote:
> I have implemented a scene graph in Haskell and I have a problem. I walk
> down the scenegraph and at each node I recalculate translation matrix and
> pass it to each child. Well it seems to be causing a stack overflow and I am
> lost as to how
I have implemented a scene graph in Haskell and I have a problem. I walk
down the scenegraph and at each node I recalculate translation matrix and
pass it to each child. Well it seems to be causing a stack overflow and I am
lost as to how to resolve the issue without issue a state variable of some
On Thu, May 28, 2009 at 14:41, Bertram Felgenhauer
wrote:
> Krzysztof Skrzętnicki wrote:
>> 2009/5/27 Bertram Felgenhauer :
>> > I wrote:
>> >> Krzysztof Skrzętnicki wrote:
>> >>> The code for modifying the counter:
>> >>> (\ msg -> atomicModifyIORef ioref (\ cnt -> (cntMsg cnt msg,(
>> >>
>>
Krzysztof Skrzętnicki wrote:
> 2009/5/27 Bertram Felgenhauer :
> > I wrote:
> >> Krzysztof Skrzętnicki wrote:
> >>> The code for modifying the counter:
> >>> (\ msg -> atomicModifyIORef ioref (\ cnt -> (cntMsg cnt msg,(
> >>
> >> atomicModifyIORef does not force the new value of the IORef.
> >>
> Thanks for the tip, although it seems tricky to get it right. I wonder
> why there is no strict version of atomicModifyIORef?
> Dually there might be a strict version of IORef datatype.
Alternatively, you could use STM, where you can write your own atomic
update function, which has the strictnes
2009/5/27 Bertram Felgenhauer :
> I wrote:
>> Krzysztof Skrzętnicki wrote:
>>> The code for modifying the counter:
>>> (\ msg -> atomicModifyIORef ioref (\ cnt -> (cntMsg cnt msg,(
>>
>> atomicModifyIORef does not force the new value of the IORef.
>> If the previous contents of the IORef is x,
I wrote:
> Krzysztof Skrzętnicki wrote:
>> The code for modifying the counter:
>> (\ msg -> atomicModifyIORef ioref (\ cnt -> (cntMsg cnt msg,(
>
> atomicModifyIORef does not force the new value of the IORef.
> If the previous contents of the IORef is x, the new contents
> will be a thunk,
>
>
Krzysztof Skrzętnicki wrote:
> The code for modifying the counter:
> (\ msg -> atomicModifyIORef ioref (\ cnt -> (cntMsg cnt msg,(
atomicModifyIORef does not force the new value of the IORef.
If the previous contents of the IORef is x, the new contents
will be a thunk,
(\ cnt -> (cntMsg cn
Hello Cafe
I'm currently writing an app with heavy use of message passing. To see
which messages takes most of the bandwidth I wrote the following code:
--
data Counter = CNT !Int !Int !Int !Int
cntMsg (CNT a b c d) (MoveOther _ _) = (CNT a+1 b c d)
cntMsg (CNT a b c d) (MoveSelf _) = (CNT a b+1
On Wed, 2009-01-14 at 19:19 +0100, Günther Schmidt wrote:
> Hello Neil,
>
> thanks, that did indeed work.
>
> I guess I shot myself in the foot a bit here ...
>
> Cause my real problem isn't actually with Map but with IxSet (from HAppS)
> which to my knowledge does not have some sort of strict
Hello Neil,
thanks, that did indeed work.
I guess I shot myself in the foot a bit here ...
Cause my real problem isn't actually with Map but with IxSet (from HAppS)
which to my knowledge does not have some sort of strict insert function.
Me trying to be really clever just used Map as a rand
Hi
> I have changed the insertion algo to use foldl to make it tail-recursive but
> still get a stack overflow as the "insert" remains lazy.
Try foldl' and insertWith' - that should work.
Thanks
Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.
Hi Eugene,
tried that, but since the action to be evaluated is the insertion into a
structure that won't work.
The strictness here doesn't go deep enough, it stopps short.
Günther
Am 14.01.2009, 18:27 Uhr, schrieb Eugene Kirpichov :
Use foldl' ?
2009/1/14 Günther Schmidt :
Hi all,
I
Hi all,
I get a stack overflow when I want to insert a huge, lazy list into a Map.
I have changed the insertion algo to use foldl to make it tail-recursive
but still get a stack overflow as the "insert" remains lazy.
Could CPS be a solution in these cases?
Günther
_
Bryan O'Sullivan wrote:
>
> On Feb 27, 2008, at 3:02 AM, Grzegorz Chrupala wrote:
>>
>> I was getting stack overflows when using Data.Binary with a few other
>> datastructures so I decided to try this option. I hacked a
>> Data.Binary.Strict module which is basically a copy and paste of
>> Data.
On Feb 27, 2008, at 3:02 AM, Grzegorz Chrupala wrote:
I was getting stack overflows when using Data.Binary with a few other
datastructures so I decided to try this option. I hacked a
Data.Binary.Strict module which is basically a copy and paste of
Data.Binary, [...]
We've recently hit the poin
Philip Armstrong wrote:
>
> On Sun, Feb 17, 2008 at 11:45:26PM +, Adrian Hey wrote:
>> But I guess this rant is not much help to the OP :-)
>
> Can the Get Monad from Data.Binary be replaced by the one in
> Data.Binary.Strict.Get?
>
> Would probably require some hacking on the library I gu
Philip Armstrong wrote:
On Mon, Feb 18, 2008 at 05:56:41PM +, Adrian Hey wrote:
Philip Armstrong wrote:
On Sun, Feb 17, 2008 at 10:01:14PM +, Adrian Hey wrote:
BTW, I find this especially ironic as fromDistinctAscList is the
perfect
example what I was talking about in another thread (c
On Mon, Feb 18, 2008 at 05:56:41PM +, Adrian Hey wrote:
Philip Armstrong wrote:
On Sun, Feb 17, 2008 at 10:01:14PM +, Adrian Hey wrote:
BTW, I find this especially ironic as fromDistinctAscList is the perfect
example what I was talking about in another thread (continuation passing
madne
Philip Armstrong wrote:
On Sun, Feb 17, 2008 at 10:01:14PM +, Adrian Hey wrote:
BTW, I find this especially ironic as fromDistinctAscList is the perfect
example what I was talking about in another thread (continuation passing
madness caused by an irrational fear of stack use).
In *some* ca
Philip Armstrong wrote:
>
> On Sun, Feb 17, 2008 at 10:01:14PM +, Adrian Hey wrote:
>> Philip Armstrong wrote:
>>> Since no-one else has answered, I'll take a stab.
>>> Obiously, you have a stack leak due to laziness somewhere
>>
>> I wouldn't say that was obvious, though it is certainly a
>
On Sun, Feb 17, 2008 at 11:45:26PM +, Adrian Hey wrote:
But I guess this rant is not much help to the OP :-)
Can the Get Monad from Data.Binary be replaced by the one in
Data.Binary.Strict.Get?
Would probably require some hacking on the library I guess.
Phil
--
http://www.kantaka.co.uk/
On Sun, Feb 17, 2008 at 10:01:14PM +, Adrian Hey wrote:
Philip Armstrong wrote:
Since no-one else has answered, I'll take a stab.
Obiously, you have a stack leak due to laziness somewhere
I wouldn't say that was obvious, though it is certainly a
possibility.
I'm never exactly clear what p
Bertram Felgenhauer wrote:
I'm fairly certain that the stack overflow is (indirectly) caused by
Data.Binary, not Data.Map.
Yes, I think you are right. At least it seems clear that the stack
overflow is not directly caused by fromDistinctAscList.
The result of 'decode' is a list of known lengt
Adrian Hey wrote:
> Philip Armstrong wrote:
>> In fact, a little experimentation has revealed that this:
>> do
>>[path] <- getArgs
>>m <- liftM decode (BS.readFile path)::IO [((Int, Maybe String), Int)]
>>putStrLn . show . findMax . fromAscList $ m
>> will work just fine. No extra eva
Philip Armstrong wrote:
Since no-one else has answered, I'll take a stab.
Obiously, you have a stack leak due to laziness somewhere
I wouldn't say that was obvious, though it is certainly a
possibility.
I'm never exactly clear what people mean by a "stack leak".
It seems some folk regard any a
On Thu, Feb 14, 2008 at 04:56:39AM -0800, Grzegorz Chrupala wrote:
I have a very simple program which reads a Data.Map from a file using
Data.Binary and Data.ByteString.Lazy, which gives stack overflow with files
over a certain size. Any ideas of what might be causing it?
You can try it with the
Hi all,
I have a very simple program which reads a Data.Map from a file using
Data.Binary and Data.ByteString.Lazy, which gives stack overflow with files
over a certain size. Any ideas of what might be causing it?
You can try it with the small file (11M) at:
http://computing.dcu.ie/~gchrupala/map
On 10/17/07, Maurício <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I get this error message when testing a function
> in ghci:
>
> *** Exception: stack overflow
>
> I admit I didn't care about efficiency when I
> wrote that function, but I'm almost sure it is not
> supposed to eat all my memory. Do I
On 10/17/07, Maurício <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I get this error message when testing a function
> in ghci:
>
> *** Exception: stack overflow
>
> I admit I didn't care about efficiency when I
> wrote that function, but I'm almost sure it is not
> supposed to eat all my memory. Do I ne
Hi,
I get this error message when testing a function
in ghci:
*** Exception: stack overflow
I admit I didn't care about efficiency when I
wrote that function, but I'm almost sure it is not
supposed to eat all my memory. Do I need to say
something to ghci if I want it to use all
available memor
Grzegorz wrote:
hammingDistance [] _ = 0
hammingDistance _ [] = 0
hammingDistance (x:xs) (y:ys) | x==y = hammingDistance xs ys
| otherwise = 1 + hammingDistance xs ys
hammingDistance xs ys = h xs ys 0
where
h [] _ n = n
h _ [] n = n
h (x:
On Friday 25 May 2007 06:50, Grzegorz wrote:
> Hi all,
> I have a simple piece of code which is giving me stack overflow. I guess I
> need to make it stricter sowhere but I can't figure out extactly where. So
> I thought I'd ask the experts.
I'm not sure. A real expert from the list will probably
Hi all,
I have a simple piece of code which is giving me stack overflow. I guess I need
to make it stricter sowhere but I can't figure out extactly where. So I thought
I'd ask the experts.
import Data.List (foldl')
import Control.Monad.State.Strict
hammingDistance [] _ = 0
hammingDistance _ [] =
Adrian Hey wrote:
Pete Kazmier wrote:
I've modified my Norvig spelling corrector to use a trie instead of
Data.Map in the hopes of improving performance. Plus, this is fun and
a great learning exercise for me. Unfortunately, when I load my trie
with a large amount of data, I get a stack overfl
Pete Kazmier wrote:
I've modified my Norvig spelling corrector to use a trie instead of
Data.Map in the hopes of improving performance. Plus, this is fun and
a great learning exercise for me. Unfortunately, when I load my trie
with a large amount of data, I get a stack overflow. It's unclear t
I've modified my Norvig spelling corrector to use a trie instead of
Data.Map in the hopes of improving performance. Plus, this is fun and
a great learning exercise for me. Unfortunately, when I load my trie
with a large amount of data, I get a stack overflow. It's unclear to
me why this is happe
Hi Bulat!
On Aug 24, 2006, at 1:07 PM, Bulat Ziganshin wrote:
Hello Brian,
Thursday, August 24, 2006, 4:16:41 PM, you wrote:
I would make all the fields strict here, to be sure that no
lazyness can
creep about unseen eg:
data Tag s = Tag {
tagID :: !Int,
state ::
Hello Gregory,
Thursday, August 24, 2006, 4:43:57 PM, you wrote:
> I agree this should be a FAQ.
we already have something like this on performance/strictness
wikipage. although adding your example of misusing $! may be helpful -
peoples are always better learned on (good and bad) examples rathe
Hello Brian,
Thursday, August 24, 2006, 4:16:41 PM, you wrote:
> I would make all the fields strict here, to be sure that no lazyness can
> creep about unseen eg:
> data Tag s = Tag {
> tagID :: !Int,
> state :: !(STRef s TagState),
> count :: !(STRef s Integer)
>
Hi Udo,
On Aug 24, 2006, at 7:22 AM, Udo Stenzel wrote:
Hi Gregory,
Gregory Wright wrote:
step :: Tag s -> ST s (Maybe Integer)
step t = do
c <- readSTRef (count t)
s <- readSTRef (state t)
writeSTRef (count t) (c - 1)
writeSTRef (state t) (nextState s)
Hi Gregory,
Gregory Wright wrote:
> step :: Tag s -> ST s (Maybe Integer)
> step t = do
> c <- readSTRef (count t)
> s <- readSTRef (state t)
> writeSTRef (count t) (c - 1)
> writeSTRef (state t) (nextState s)
> if (c <= 0) then return Nothing else return (J
Hi Bulat,
On Aug 24, 2006, at 7:52 AM, Bulat Ziganshin wrote:
Hello Gregory,
Thursday, August 24, 2006, 2:29:15 PM, you wrote:
step t = do
c <- readSTRef (count t)
s <- readSTRef (state t)
writeSTRef (count t) (c - 1)
writeSTRef (state t) (nextState s)
Gregory Wright wrote:
-- A structure with internal state:
--
data Tag s = Tag {
tagID :: Int,
state :: STRef s TagState,
count :: STRef s Integer
}
data FrozenTag = FrozenTag {
ft_tagID :: Int,
ft_state :: TagState,
ft_count :: Integer
} deriving
Hello Gregory,
Thursday, August 24, 2006, 2:29:15 PM, you wrote:
> step t = do
> c <- readSTRef (count t)
> s <- readSTRef (state t)
> writeSTRef (count t) (c - 1)
> writeSTRef (state t) (nextState s)
> if (c <= 0) then return Nothing else return (Just
The write*Ref functions, like many "write into data structure" have the common
problem of being much lazier than you want. The nextState calls form a lazy
thunk. In fact it tries form 10^6 nested thunks to call nextState. So you have
to use something like seq to reduce the laziness:
step
Hi,
I have a program, abstracted from a larger application that I am
writing for a customer, that persistently overflows its stack. The
program is a simulation of the communication protocol of a
sensor tag. The code is below.
The program mimics a hardware state machine. In the example
below,
--- Tomasz Zielonka <[EMAIL PROTECTED]>
wrote:
> On Thu, Sep 02, 2004 at 08:47:51AM -0700, Ron de
> Bruijn wrote:
> > I heard of the +RTS option. I used:
> > ghci SomeModule.hs -someoptions +RTS -K150,
> but
> > this doesn't seem to have any effect.
>
> Try +RTS -K150M.
> -K150 means 15
On Thu, Sep 02, 2004 at 08:47:51AM -0700, Ron de Bruijn wrote:
> I heard of the +RTS option. I used:
> ghci SomeModule.hs -someoptions +RTS -K150, but
> this doesn't seem to have any effect.
Try +RTS -K150M.
-K150 means 150 bytes.
Best regards,
Tom
--
.signature: Too many levels of
I have an expression that gives a stack overflow in
ghci (official Debian unstable CVS version)) when I
evaluate it. The expression doesn't use more than
150MB of memory (I have more). How can I make sure the
stack overflow doesn't happen?
There are no strictness flags in my program. But I use
DDa
65 matches
Mail list logo
