I've got the following printHex string as a response from a 9P server
running on the Inferno Operating System. (thanks to a friendly mailing list
contributor who sent a nice example of using Data.Binary)
13006500040600395032303030
This is a little endian encoded ByteString with the
I think getRemainingLazyByteString expects at least one byte (this,
perhaps, is not the appropriate behavior). You'll want to wrap your
call to getRemainingLazyByteString with a call to
Data.Binary.Get.remaining[1] like this:
foo = do
r - remaining
rbs - case r of
0 -
I think getRemainingLazyByteString expects at least one byte
No, it works with an empty bytestring. Or, my tests do with binary 0.5.0.1.
The specific error means you are requiring more data than providing.
First check the length of the bytestring you pass in to the to level
decode (or 'get')
Thomas,
You're correct. For some reason, I based my advice on the thought that
19 was the minimum size instead of 13.
On Tue, Jun 2, 2009 at 1:24 PM, Thomas DuBuisson
thomas.dubuis...@gmail.com wrote:
I think getRemainingLazyByteString expects at least one byte
No, it works with an empty
The thing is I have 19 bytes in the hex string I provided:
13006500040600395032303030
That's 38 characters or 19 bytes.
The last 4 are 9P2000
1300 = 4 bytes for 32bit message payload, This is little endian for 19
bytes total.
65 = 1 byte for message type. 65 is Rversion or
I think Thomas' point was that some other branch in `getSpecific' is
running. Is there a chance we can see the rest of `getSpecific'?
On Tue, Jun 2, 2009 at 4:20 PM, David Leimbach leim...@gmail.com wrote:
The thing is I have 19 bytes in the hex string I provided:
On Tue, Jun 2, 2009 at 10:24 AM, Thomas DuBuisson
thomas.dubuis...@gmail.com wrote:
I think getRemainingLazyByteString expects at least one byte
No, it works with an empty bytestring. Or, my tests do with binary
0.5.0.1.
The specific error means you are requiring more data than providing.
On Tue, Jun 2, 2009 at 1:28 PM, John Van Enk vane...@gmail.com wrote:
I think Thomas' point was that some other branch in `getSpecific' is
running. Is there a chance we can see the rest of `getSpecific'?
Sure: (In the meantime, I'll try the suggested code from before)
get = do s -
Perhaps there's some place in your code that's forcing the lazy read
to consume more. Perhaps you could replace it with an explict (and
strict) getBytes[1] in combination with remaining[2]?
Is there a reason you want to use lazy byte strings rather than
forcing full consumption? Do the 9P packets
What happens if you use `getRemainingLazyByteString' in your error
branch instead of `getLazyByteString'?
On Tue, Jun 2, 2009 at 4:31 PM, David Leimbach leim...@gmail.com wrote:
On Tue, Jun 2, 2009 at 1:28 PM, John Van Enk vane...@gmail.com wrote:
I think Thomas' point was that some other
On Tue, Jun 2, 2009 at 1:32 PM, John Van Enk vane...@gmail.com wrote:
Perhaps there's some place in your code that's forcing the lazy read
to consume more. Perhaps you could replace it with an explict (and
strict) getBytes[1] in combination with remaining[2]?
Unfortunately, I'm using a Lazy
On Tue, Jun 2, 2009 at 1:36 PM, John Van Enk vane...@gmail.com wrote:
What happens if you use `getRemainingLazyByteString' in your error
branch instead of `getLazyByteString'?
I actually am using getRemainingLazyByteString right now, and it still
thinks I'm asking for a 20th byte.
if I
Again, I can't reproduce your problem. Are you getting data through
some previous Binary instance before calling the routines you show us
here? The code I tested with is below - I've tried it with both
'getSpecific' paths by commenting out one path at a time. Both
methods work, shown below.
Just so we know that it's not the issue, what version of binary are
you using? The most current one is 0.5.0.1.
On Tue, Jun 2, 2009 at 4:46 PM, David Leimbach leim...@gmail.com wrote:
On Tue, Jun 2, 2009 at 1:36 PM, John Van Enk vane...@gmail.com wrote:
What happens if you use
0.5.0.1
On Tue, Jun 2, 2009 at 1:56 PM, John Van Enk vane...@gmail.com wrote:
Just so we know that it's not the issue, what version of binary are
you using? The most current one is 0.5.0.1.
On Tue, Jun 2, 2009 at 4:46 PM, David Leimbach leim...@gmail.com wrote:
On Tue, Jun 2, 2009 at
On Tue, Jun 2, 2009 at 1:56 PM, Thomas DuBuisson thomas.dubuis...@gmail.com
wrote:
Again, I can't reproduce your problem. Are you getting data through
some previous Binary instance before calling the routines you show us
here?
Ah good question... I'm calling decode, but it's not clear that
It will run the instance of the inferred type (or you can provide a
type signature to force it). I've done this often before with lists -
trying to read in some arbitrary, typically high, number of elements
causes issues :-)
Thomas
On Tue, Jun 2, 2009 at 2:07 PM, David Leimbach
On Tue, Jun 2, 2009 at 2:07 PM, David Leimbach leim...@gmail.com wrote:
On Tue, Jun 2, 2009 at 1:56 PM, Thomas DuBuisson
thomas.dubuis...@gmail.com wrote:
Again, I can't reproduce your problem. Are you getting data through
some previous Binary instance before calling the routines you
18 matches
Mail list logo
