bos:
Adam Langley wrote:
Ok, see http://www.imperialviolet.org/IncrementalGet.hs
That's excellent! This is just the sort of thing one wants if getting
dribs and drabs of information instead of a steady stream. For example,
I need to reconstruct TCP streams from individual packets
On Jan 7, 2008 11:17 AM, Bryan O'Sullivan [EMAIL PROTECTED] wrote:
It would seem that there would be three possible outcomes from an
incremental Get:
- Failure: some bitstreams are just invalid and no amount of extra
data will ever fix that
- Complete [Result]: the last chunk of data
Adam Langley wrote:
Ok, see http://www.imperialviolet.org/IncrementalGet.hs
That's excellent! This is just the sort of thing one wants if getting
dribs and drabs of information instead of a steady stream. For example,
I need to reconstruct TCP streams from individual packets captured off
the
On Jan 6, 2008 9:13 PM, Bryan O'Sullivan [EMAIL PROTECTED] wrote:
Ooh, nice. We could really do with an incremental version, too, which
could be spoonfed chunks of bytes, and dole out values as
deserialisation completes.
Passing back a Left String is in some sense not much of an improvement
It would seem that there would be three possible outcomes from an
incremental Get:
- Failure: some bitstreams are just invalid and no amount of extra
data will ever fix that
- Complete [Result]: the last chunk of data has been processed.
Maybe this should also include the remainder of
Over the Xmas break I made some headway on writing an RPC package
since many of the ideas that I want to play with involve such a thing
as a basic building block. However, some might find some of the
spin-off packages that I wrote along the way useful.
* binary-strict:
This is mostly a
Adam Langley wrote:
This is mostly a cut-n-paste job from the excellent binary package
which provides Data.Binary.Strict.Get - a monad which is a drop in
replacement for Get, but which parses strict ByteStrings and returns
an Either,
Ooh, nice. We could really do with an incremental
