Is the Protocol Buffers supports WinCE platform?
Thanks
Prasad.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe
It looks like you are assuming that sends and receives on your TCP stream
will match up 1:1. This isn't actually the case. A TCP connection is a
stream of bytes, not packets. A single read on the receiving end may
receive only part of a packet, or it may receive multiple packets.
So, you really
It looked like this before i sent the data: (Debug)
type: 14
Login {
name: "Test"
password: "nil"
}
And i got this on the receiving end: (Debug)
type: 14
Login {
14 {
}
}
I can't figure out what in the world which could be changing data...
Notice: I am using wxWidgets for UI and SFML fo
I don't see anything wrong with your code. What kind of error are you
seeing? Are you sure that the bytes you passed in to the parser on the
receiving end are exactly the same as what came out of the serializer on the
sending side?
On Sun, Nov 9, 2008 at 6:40 AM, <[EMAIL PROTECTED]> wrote:
>
>
On Mon, Nov 10, 2008 at 9:12 AM, Chris Kuklewicz <[EMAIL PROTECTED]>wrote:
> BUG * The user-defined options have the wrong value for some 32 bit
> value.
Looks like you figured this out. Yeah, the idea is that 32-bit varints and
64-bit varints should always be compatible. So, if you write a 32
Okay, I spoke too soon on the first bug.
From http://code.google.com/apis/protocolbuffers/docs/encoding.html :
"If you use int32 or int64 as the type for a negative number, the
resulting varint is always ten bytes long – it is, effectively, treated
like a very large unsigned integer."
So it i
Kenton,
I am nearly ready with the Haskell update to protoc [1] that will
support the user defined options introduced by protocol-buffers 2.0.2
(protoc).
To have a hope of testing my code, I have redesigned my processing to
have hprotoc produce a binary FileDescriptorSet that I could compare
to
