If you want to auto-restart after all errors, another way to write it is:
import qualified Data.Attoparsec.Types as Attoparsec
import Pipes.Parse
import Pipes.Attoparsec (ParserInput, parse)
keepGoing
:: (Monad m, ParserInput a)
=> Attoparsec.Parser a b
-> Producer a m r -> Producer b m r
keepGoing parser p = do
(x, p') <- lift $ runStateT (parse parser) p
case x of
Left _ -> return ()
Right b -> yield b
keepGoing parser p'
Note that until Renzo releases `pipes-attoparsec-4.1.0` this will be
inefficient because of my mistake in writing `parse`, but once he fixes
the efficiency of `parse` then this will be more efficient than using
`errorP`. Generally, all the functions in `Pipes.Lift` are slow, so
they should be used with caution.
On 3/13/2014 2:48 PM, Kai Wang wrote:
Indeed, I don't care about the leftovers. Does this mean that my
pipeline should look like this:
myPipe :: Socket
-> Output Word8
-> Effect ErrorT ((ParsingError, Producer ByteString m ()) m) ()
myPipe s o = loop >-> toOutput o
where
loop = forever $ (errorP . parsed myParser $ fromSocket s 4096)
myParser = undefined -- some attoparsec parser
On Thursday, March 13, 2014 12:49:20 PM UTC-7, Danny Navarro wrote:
Another thing to consider is whether you want to handle parsing
errors
and the leftovers. If you just want the parsing pipe to terminate
when
errors occur and you don't care about the leftovers when (or if) the
pipe is done parsing, you may not need `pipes-parse` at all, and
could
get away just using `pipes` and `pipes-concurrency`.
On Thu, Mar 13, 2014 at 8:02 PM, Renzo Carbonara
<[email protected] <javascript:>> wrote:
> On Thu, Mar 13, 2014 at 3:41 PM, Kai Wang <[email protected]
<javascript:>> wrote:
>> Hi:
>>
>> Suppose I have a Bytestring producer, I want to use
>> pipes-attoparsec/binary/etc to parse this producer, and send
the result to a
>> pipes-concurrent output mailbox. What's the idiomatic to
achieve this
>> result? Is using "parse :: A.Parser a b -> P.Parser a m (Either
ParsingError
>> b)" (from pipes-attoparsec) the correct approach for this
situation? or
>> should I stick with "parsed :: A.Parser a b -> P.Producer a m r ->
>> P.Producer b m (Either (ParsingError P.Producer a m r) r)"
(also from
>> pipes-attoparsec)
>
> Kai,
>
>
> It depends on the contents of your original `ByteString`
producer and
> on how you want to deal with parsing errors.
>
> If your original `ByteString` producer contains consecutive raw
> entries that can be parsed with nothing else in between them, then
> `Pipes.Attoparsec.parsed` will work; you'll just have to take
care of
> matching the `Either (ParsingError, Producer a m r) r` return type
> from this new producer with the other `Proxy`s in your pipeline.
For
> example, `pipes-concurrency`'s `toOutput`'s return value is
> incompatible with said return type, but you could use
> `Pipes.Lift.errorP` to reconcile them.
>
> Otherwise, if your original `ByteString` producer contains
additional
> content in between each raw entry or you want to deal with parsing
> errors locally, then you should rely on `Pipes.Attoparsec.parse`
and
> the infrastructure provided by `pipes-parse.
>
>
> Regards,
>
> Renzo Carbonara.
>
> --
> You received this message because you are subscribed to the
Google Groups "Haskell Pipes" group.
> To unsubscribe from this group and stop receiving emails from
it, send an email to [email protected] <javascript:>.
> To post to this group, send email to [email protected]
<javascript:>.
--
You received this message because you are subscribed to the Google
Groups "Haskell Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
--
You received this message because you are subscribed to the Google Groups "Haskell
Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
