On Sun, Jul 20, 2008 at 09:55:15AM -0400, Isaac Dupree wrote:
It doesn't stop it from parsing the entire file strictly. However, what
it does do is prevent the parser from backtracking out of arbitrary
amounts of lookahead. So, unless you use try (which allows for
lookahead), when any token
On Sun, Jul 20, 2008 at 02:34:09AM +0400, Bulat Ziganshin wrote:
i think that Parsec library should hold entire file in memory only when
you use 'try' for whole file. otherwise it should omit data as
proceeded
I do not believe that is the case, since the return type of runParser
Either
On Sunday 20 July 2008, John Meacham wrote:
I do not believe that is the case, since the return type of runParser
Either ParseError a means that before you can extract the result of
the parse from the 'Right' branch, it must evaluate whether the result
is 'Left' or 'Right' meaning it needs to
On Sun, Jul 20, 2008 at 7:25 AM, Chaddaï Fouché [EMAIL PROTECTED]
wrote:
That's exactly what I thought. But even if I remove the only 'try' I use
the
memory consumption remains unchanged:
It's true, but in your case your output is almost the raw input data,
which means that even without
Dan Doel wrote:
On Sunday 20 July 2008, John Meacham wrote:
I do not believe that is the case, since the return type of runParser
Either ParseError a means that before you can extract the result of
the parse from the 'Right' branch, it must evaluate whether the result
is 'Left' or 'Right'
I played with another approach without any parser library, just with plain
pattern matching. The idea was to create function to match all different
cases of codes. Since I already got most of the code, it was quite easy to
do. The core function consist of cases like those:
parse
2008/7/19 Krzysztof Skrzętnicki [EMAIL PROTECTED]:
Hi all
1) Profiling shows that very simple functions are source of great memory and
time consumption. However, if I turn them off and simply print their input
arguments instead, the overall time and memory consumption doesn't change.
But now
I forgot to mention that the memory consumption is several times higher than
file size. On 8,3 Mb file:
532 MB total memory in use (4 MB lost due to fragmentation).
Having that 8 Mb in memory is not the problem. 532 Mb is another story. In
general, the program consumes roughly 64 times more
Hello Krzysztof,
Sunday, July 20, 2008, 12:49:54 AM, you wrote:
on the 32-bit computers 36x memreqs for storing large strings in
memory is a rule, on 64-bit ones - 72x
I forgot to mention that the memory consumption is several times
higher than file size. On 8,3 Mb file:
532 MB total memory
2008/7/19 Krzysztof Skrzętnicki [EMAIL PROTECTED]:
I forgot to mention that the memory consumption is several times higher than
file size. On 8,3 Mb file:
532 MB total memory in use (4 MB lost due to fragmentation).
Having that 8 Mb in memory is not the problem. 532 Mb is another story. In
On Sat, Jul 19, 2008 at 11:35 PM, Chaddaï Fouché [EMAIL PROTECTED]
wrote:
2008/7/19 Krzysztof Skrzętnicki [EMAIL PROTECTED]:
I forgot to mention that the memory consumption is several times higher
than
file size. On 8,3 Mb file:
532 MB total memory in use (4 MB lost due to fragmentation).
Hello Krzysztof,
Sunday, July 20, 2008, 1:55:45 AM, you wrote:
532 MB total memory in use (4 MB lost due to fragmentation).
i think that Parsec library should hold entire file in memory only when
you use 'try' for whole file. otherwise it should omit data as
proceeded
--
Best regards,
Bulat
On Sun, Jul 20, 2008 at 12:34 AM, Bulat Ziganshin [EMAIL PROTECTED]
wrote:
Hello Krzysztof,
Sunday, July 20, 2008, 1:55:45 AM, you wrote:
532 MB total memory in use (4 MB lost due to fragmentation).
i think that Parsec library should hold entire file in memory only when
you use 'try' for
2008/7/20 Krzysztof Skrzętnicki [EMAIL PROTECTED]:
On Sun, Jul 20, 2008 at 12:34 AM, Bulat Ziganshin
[EMAIL PROTECTED] wrote:
Hello Krzysztof,
Sunday, July 20, 2008, 1:55:45 AM, you wrote:
532 MB total memory in use (4 MB lost due to fragmentation).
i think that Parsec library should
14 matches
Mail list logo
