Re: [Haskell-cafe] Success and one last issue with Data.Binary

2 Jun 2009


      On Tue, Jun 2, 2009 at 1:32 PM, John Van Enk  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 ByteString network IO lib.  So I don't think
going to a strict ByteString is going to be possible.
...
Is there a reason you want to use lazy byte strings rather than
forcing full consumption? Do the 9P packets generally have a lot of
trailing useless data?
Nope.  Just I noticed that there was a Network ByteString package that
utilized lazy bytestrings :-).

Even if that's why it's going for a 20th byte, shouldn't that be a bug?  :-)
...
1.
http://hackage.haskell.org/packages/archive/binary/0.5.0.1/doc/html/Data-Bin...
2.
http://hackage.haskell.org/packages/archive/binary/0.5.0.1/doc/html/Data-Bin...
On Tue, Jun 2, 2009 at 4:28 PM, David Leimbach  wrote:
...
On Tue, Jun 2, 2009 at 10:24 AM, Thomas DuBuisson
 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.
I've shown that I am not trying to decode more than I'm providing.  I've
asked, expliciitly, for 13 bytes, and then "remaining", and the library
...
complaining about the 20th byte.
...
First check the length of the bytestring you pass in to the to level
decode (or 'get') routine and walk though that to figure out how much
it should be consuming.  I notice you have a guard on the
'getSpecific' function, hopefully you're sure the case you gave us is
the branch being taken.
The other branch is Rerror, which is a shorter message decode stream.
 Unfortunately, I can't get Debug.Trace to show anything to prove it's
taking this fork of the code.  I suppose I could unsafePerformIO :-)
Perhaps I just need a new version of "binary"??  I'll give it a go and
is
try
...
your version.  But I need to decode over a dozen message types, so I will
need a case or guard or something.
Dave
...
I think the issue isn't with the code provided.  I cleaned up the code
(which did change behavior due to the guard and data declarations that
weren't in the mailling) and it works fine all the way down to the
expected minimum of 13 bytes.
...
import Data.ByteString.Lazy
import Data.Binary
import Data.Binary.Get
data RV =
Rversion {     size   :: Word32,
               mtype  :: Word8,
               tag    :: Word16,
               msize  :: Word32,
               ssize  :: Word16,
               version :: ByteString}
      deriving (Eq, Ord, Show)
...
instance Binary RV where
 get = do s <- getWord32le
         mtype <- getWord8
         getSpecific s mtype
  where
   getSpecific s mt = do t <- getWord16le
                         ms <- getWord32le
                         ss <- getWord16le
                         v <- getRemainingLazyByteString
                         return $ Rversion {size=s,
                                            mtype=mt,
                                            tag=t,
                                            msize=ms,
                                            ssize=ss,
                                            version=v }
 put _ = undefined
--
/jve