> Oh yes, one more datum. If I run hs_perform_gc before each and every
> mallocForeignPtrBytes and reallocBytes, the leak goes much
> more slowly, and
> the code gets much further in the job before getting killed.
> But it still
> leaks, and still gets killed.
It could potentially be a memor
On Wed, Oct 01, 2003 at 11:02:52AM +0100, Simon Marlow wrote:
>
> > Oh yes, one more datum. If I run hs_perform_gc before each and every
> > mallocForeignPtrBytes and reallocBytes, the leak goes much more slowly,
> > and the code gets much further in the job before getting killed. But
> > it st
Hi, I have just started using Haskell, and it has been really fun so far.
But I have problems with memory usage when handling large files. What I do
is the following;
I load my file in one chunk, and does a lot of substitutes on the string -
this is quick eating all my memory and the computers sta
Am Mittwoch, 1. Oktober 2003, 15:18 schrieb Petter Egesund:
> [...]
> The problem is of course that the string is copied each time I do a
> substitute, and I wonder if a more experienced haskeller has a better
> solution to my problem.
It doesn't have to be a problem that the string is copied eac
Hi & thanks for answering;
I should have been more precise, my function works like this:
fun :: String -> String
look for pat1 in string - if found subst with sub1
look for pat2 in string - if found subst with sub2
look for pat3 in string - if found subst with sub3
recur
> This sounds like a good plan (I do have a ghc build around).
> How do I go
> about compiling a debugging RTS?
Add the following to mk/build.mk:
GhcRtsHcOpts = -optc-DDEBUG
GhcRtsCcOpts = -g
then go into ghc/rts and 'make clean && make'. Now rebuild your program
using this GHC (or alte
[ taking this one to haskell-café... ]
> I still do not quite agree with Simon that 'interact' exposes anything
> but non-strictness. Non-strictness means that
>
> map toUpper _|_ = _|_
> map toUpper ('a':_|_) = ('A':_|_)
> map toUpper ('a':'b':_|_) = ('A':'B':_|_)
>
> and 'interact (map t
I'm trying the add-a-gram challenge from here:
http://www.itasoftware.com/careers/programmers-archive.php
... and I'm also experiencing runaway memory consumption. If I load the
supplied list of words (a 1.6M file) and search for shorter strings, things
are OK. Memory consumption increases dramati
[snip]
> Certainly you can observe non-strictness, that's not the point. The point is
> that you can also observe more than just non-strictness using interact, and I
> don't think that is desirable. For example:
>
> interact (\xs -> let z = length xs in "Hello World\n")
>
> Now, Haskell is
Simon Marlow wrote:
> Certainly you can observe non-strictness, that's not the point. The point is that
> you can also observe more than just non-strictness using interact, and I don't think
> that is desirable. For example:
>
> interact (\xs -> let z = length xs in "Hello World\n")
>
> Now
Robert Ennals wrote:
> It is wrong for all the same reasons that unsafePerformIO is wrong, except
> that it is worse than that because unsafePerformIO has "unsafe" in the title,
> and people are discouraged from using it without due care. By contrast,
> "interact" and "getContents" are presented as
> Yes, the presence of lazy IO makes optimistic evaluation more
> complicated, but I do not see that it compromises the purity of the
> language in anyway (whatever purity is ;-).
So, we're agreed that the presence of lazy evaluation makes implementing
optimistic evaluation (and other evaluation s
Simon Marlow wrote:
The real problem is that lazy I/O injects side effects into the pure
world of expressions. Haskell has a perfectly good system for
encapsulating side effects - the IO monad. So why put these sneaky side
effects into pure values?
Although monadic IO is nice in many ways, I
13 matches
Mail list logo
