On Sat, 2008-01-12 at 21:39 -0800, Jonathan Cast wrote:
> No. A cell is generated once either (a) it, or (b) a cell earlier in
> the list, is required. A cell is garbage collected once both (a) it,
> and (b) all cells earlier in the list, are no longer required. So if
> you process the lis
On 12 Jan 2008, at 4:42 PM, Andre Nathan wrote:
On Sat, 2008-01-12 at 16:00 -0800, Jonathan Cast wrote:
Wait, the last entry? If you're just printing out the values, then
no --- those should have been garbage collected already.
Won't they be garbage collected only after the last entry is use
On Jan 13, 2008 12:42 AM, Andre Nathan <[EMAIL PROTECTED]> wrote:
> On Sat, 2008-01-12 at 16:00 -0800, Jonathan Cast wrote:
> > Wait, the last entry? If you're just printing out the values, then
> > no --- those should have been garbage collected already.
>
> Won't they be garbage collected only a
On Sat, 2008-01-12 at 16:00 -0800, Jonathan Cast wrote:
> Wait, the last entry? If you're just printing out the values, then
> no --- those should have been garbage collected already.
Won't they be garbage collected only after the last entry is used,
though? Since getDirectoryEntries returns a
On 12 Jan 2008, at 10:26 AM, Andre Nathan wrote:
On Sat, 2008-01-12 at 10:11 -0800, Jonathan Cast wrote:
A nit: the list is almost certainly getting created lazily, or you'd
get more than 300% more memory usage. But you still get the list's
cons cells as your bookkeeping baggage, and they take
On 12 Jan 2008, at 10:26 AM, Andre Nathan wrote:
On Sat, 2008-01-12 at 10:11 -0800, Jonathan Cast wrote:
A nit: the list is almost certainly getting created lazily, or you'd
get more than 300% more memory usage. But you still get the list's
cons cells as your bookkeeping baggage, and they take
On Sat, 2008-01-12 at 10:11 -0800, Jonathan Cast wrote:
> A nit: the list is almost certainly getting created lazily, or you'd
> get more than 300% more memory usage. But you still get the list's
> cons cells as your bookkeeping baggage, and they take up space in
> exchange for greater flexi
On 12 Jan 2008, at 7:19 AM, Andre Nathan wrote:
On Fri, 2008-01-11 at 19:14 -0800, Jonathan Cast wrote:
These are all known and expected. As I said, you can expect lazy
versions to normally be slower than explicit loops. The question is
whether 50% more time and 300% more memory has a higher
On Fri, 2008-01-11 at 19:14 -0800, Jonathan Cast wrote:
> These are all known and expected. As I said, you can expect lazy
> versions to normally be slower than explicit loops. The question is
> whether 50% more time and 300% more memory has a higher cost in your
> case than the extra compl
On 11 Jan 2008, at 2:24 PM, Andre Nathan wrote:
processEntry :: DirStream -> IO ()
processEntry ds = do
entry <- readDirStream ds
if entry =~ "^[0-9]+$"
then do
putStrLn entry
processEntry ds
else
if entry == "" then return () else processEntry ds
bar :: IO ()
bar
On 11 Jan 2008, at 2:20 PM, Andre Nathan wrote:
On Fri, 2008-01-11 at 13:27 -0200, Andre Nathan wrote:
I was wondering if laziness would make it run as if it was a
single O(n)
operation (get one directory entry "on demand", pass it to filter and
then to insertInTree), because only one entry i
On 11 Jan 2008, at 7:27 AM, Andre Nathan wrote:
On Thu, 2008-01-10 at 20:37 -0800, Jonathan Cast wrote:
It might be faster; laziness usually has higher constants than direct
implementations. But I doubt the difference is critical in this
case, and I would definitely time a re-writing and throw
On Fri, 2008-01-11 at 20:20 -0200, Andre Nathan wrote:
> Both versions which use getDirectoryContents also use much more memory
> than the one which uses readDirStream (about 8M vs about 2M). Maybe I'm
> not exploting getDirectoryContents' laziness correctly? I expected the
> second and third versi
On Fri, 2008-01-11 at 13:27 -0200, Andre Nathan wrote:
> I was wondering if laziness would make it run as if it was a single O(n)
> operation (get one directory entry "on demand", pass it to filter and
> then to insertInTree), because only one entry is used at a time, so that
> only the "current" e
On Thu, 2008-01-10 at 20:37 -0800, Jonathan Cast wrote:
> It might be faster; laziness usually has higher constants than direct
> implementations. But I doubt the difference is critical in this
> case, and I would definitely time a re-writing and throw it away
> unless it was significantly f
On 10 Jan 2008, at 10:21 AM, Andre Nathan wrote:
Hi Jonathan
On Wed, 2008-01-09 at 21:32 -0800, Jonathan Cast wrote:
An actual coding question, abuse? We should be so lucky.
:) Your comments are much appreciated.
You're welcome.
This function is fairly complicated, simply because of the
Hi Jonathan
On Wed, 2008-01-09 at 21:32 -0800, Jonathan Cast wrote:
> An actual coding question, abuse? We should be so lucky.
:) Your comments are much appreciated.
> This function is fairly complicated, simply because of the number of
> separate definitions involved; I would be looking for
On 9 Jan 2008, at 7:57 PM, Andre Nathan wrote:
Hello
I've just found time to finish writing my first "real world"
program, so
I thought I'd post it here and ask for insight on general issues
such as
if there's anything that isn't done "the Haskell way", or if there's
something that could b
Hello
I've just found time to finish writing my first "real world" program, so
I thought I'd post it here and ask for insight on general issues such as
if there's anything that isn't done "the Haskell way", or if there's
something that could be done more efficiently.
The code is at the bottom of
19 matches
Mail list logo
