Andrew Pimlott wrote:
On Tue, Sep 20, 2005 at 03:01:32PM +0100, Keean Schupke wrote:
(see attachment for files)
You didn't include all the used libraries (MonadControl, MonadState).
Andrew
Oops, here they are (it was extracted from a larger project), sorry
about that...
(Have
On Sep 20, 2005, at 6:32 PM, Benjamin Franksen wrote:
On Tuesday 20 September 2005 16:50, John Goerzen wrote:
On the flip side, Parsec is really nice. I wonder how easy it would
be to make it parse [Word8] instead of String?
Isn't Parsec parameterized over the token type?
Or even a
On Wednesday 21 September 2005 19:36, Jan-Willem Maessen wrote:
On Sep 20, 2005, at 6:32 PM, Benjamin Franksen wrote:
On Tuesday 20 September 2005 16:50, John Goerzen wrote:
On the flip side, Parsec is really nice. I wonder how easy it
would be to make it parse [Word8] instead of String?
On Wed, Sep 21, 2005 at 12:32:56AM +0200, Benjamin Franksen wrote:
On Tuesday 20 September 2005 16:50, John Goerzen wrote:
On the flip side, Parsec is really nice. I wonder how easy it would
be to make it parse [Word8] instead of String?
Isn't Parsec parameterized over the token type?
On Wednesday 21 September 2005 20:17, John Meacham wrote:
On Wed, Sep 21, 2005 at 12:32:56AM +0200, Benjamin Franksen wrote:
On Tuesday 20 September 2005 16:50, John Goerzen wrote:
On the flip side, Parsec is really nice. I wonder how easy it
would be to make it parse [Word8] instead of
On 2005-09-16, Andrew Pimlott [EMAIL PROTECTED] wrote:
On Thu, Sep 15, 2005 at 06:11:58PM -0700, Andrew Pimlott wrote:
I don't see why this would be more error-prone than any other approach.
Hmm... I take that back. I don't know anything about the IMAP protocol,
but after imagining for a few
On 2005-09-15, Adam Turoff [EMAIL PROTECTED] wrote:
On 9/15/05, John Goerzen [EMAIL PROTECTED] wrote:
So, to make that approach work, I would really need to do a lot of work
outside of Parsec -- the stuff that I really want to use Parsec for, I
think.
Well, you do have a state monad to work
John Goerzen wrote:
On 2005-09-15, Adam Turoff [EMAIL PROTECTED] wrote:
On 9/15/05, John Goerzen [EMAIL PROTECTED] wrote:
So, to make that approach work, I would really need to do a lot of work
outside of Parsec -- the stuff that I really want to use Parsec for, I
think.
Well,
You may like my parser transformer then (based on the efficent
backtracking parser paper, I believe by Ralf Heinze - uses endofunctor
and continuation passing - Its a long time since I tested it but I think
it holds its own against Parsec, without requiring the extra return types).
--
On Tue, Sep 20, 2005 at 02:29:12PM +0100, Keean Schupke wrote:
It's unclear to me exactly how to mix the IO monad with Parsec. It
doesn't really seem to be doable.
Not to mention that if hGetContents is used, the Handle has to be put
into non-buffering mode, which means one syscall per
Here's some useful definitions to go with that...
module Lib.Parser.Parser(Parser,when,unless,guard,(|),opt,many,many1,sepBy,
parse,alpha,digit,lower,upper,other,lexical,satisfy,optional,literal,untilP,untilParser,matchP)
where ...
(see attachment for files)
Regards,
Keean.
John Goerzen wrote:
On Tue, Sep 20, 2005 at 02:29:12PM +0100, Keean Schupke wrote:
It's unclear to me exactly how to mix the IO monad with Parsec. It
doesn't really seem to be doable.
Not to mention that if hGetContents is used, the Handle has to be put
into non-buffering mode, which
On Tue, Sep 20, 2005 at 03:05:25PM +0100, Keean Schupke wrote:
strace seems to say yes.
Thats odd, the source code seems to suggest that when you read past the
end of the buffer
it reads the next entire buffer (it has cases for each possible buffer
configuration, line, block and none)
Here's the code from hGetContents (base/GHC/IO.lhs):
-- we never want to block during the read, so we call fillReadBuffer
with
-- is_line==True, which tells it to just read what there is.
lazyReadBuffered h handle_ fd ref buf = do
catch
(do buf - fillReadBuffer fd
John Goerzen wrote:
On Tue, Sep 20, 2005 at 03:05:25PM +0100, Keean Schupke wrote:
strace seems to say yes.
Thats odd, the source code seems to suggest that when you read past the
end of the buffer
it reads the next entire buffer (it has cases for each possible buffer
On Tue, Sep 20, 2005 at 03:20:01PM +0100, Keean Schupke wrote:
Because the next entire buffer might consume more data than the remote
has sent. That results in deadlock.
Would it not be usual to have a timeout incase of dropped connection?
Yes, but hardly useful if it happens after
On Tue, Sep 20, 2005 at 03:17:11PM +0100, Keean Schupke wrote:
-- For a line buffer, we just get the first chunk of data to arrive,
-- and don't wait for the whole buffer to be full (but we *do* wait
-- until some data arrives). This isn't really line buffering, but it
-- appears
On Tuesday 20 September 2005 16:50, John Goerzen wrote:
On the flip side, Parsec is really nice. I wonder how easy it would
be to make it parse [Word8] instead of String?
Isn't Parsec parameterized over the token type?
Or even a
FastPackedString? (And how easy it would be to get that
John Goerzen writes:
With networking, you must be careful not to attempt to
read more data than the server hands back, or else you'll
block. [...] With a protocol such as IMAP, there is no
way to know until a server response is being parsed, how
many lines (or bytes) of data to read.
On 2005-09-15, Peter Simons [EMAIL PROTECTED] wrote:
The approach I recommend is to run a scanner (tokenizer)
before the actual parser.
IMAP, like most other RFC protocols, is line-based; so you
can use a very simple scanner to read a CRLF-terminated line
efficiently (using non-blocking I/O,
On 9/15/05, John Goerzen [EMAIL PROTECTED] wrote:
Not only that, but IMAP has a way where you can embed, say {305} instead
of a string. That means, after you finish reading this line, read
exactly 305 bytes, and consider that to be used here. But if you see
{305} (the double quotes
21 matches
Mail list logo
