On Wed, Jul 14, 2010 at 1:36 AM, bwp wrote:
> Our protocol consists of a big number of possible messages but I can't
> seem to find a way for protobuf to help me decide which message was
> sent.
> Writing and parsing messages is really easy when I know what exact
> message is being sent but this w
message type in.
--Pete
On Tue, Dec 1, 2009 at 12:13 PM, Peter Keen wrote:
> Is there a reason why you can't compile the message types into the
> message editor? It seems like they're pretty intimately tied together
> as it is.
>
> --Pete
>
> On Tue, Dec 1, 2009 at
Is there a reason why you can't compile the message types into the
message editor? It seems like they're pretty intimately tied together
as it is.
--Pete
On Tue, Dec 1, 2009 at 10:27 AM, David McClurg wrote:
> I'm trying to rebuild a message editor for a game engine using
> protocol buffers. Cu
On Wed, Oct 28, 2009 at 4:37 PM, Kenton Varda wrote:
> The code generator should generate exactly the same code regardless of the
> parser version, since newer parsers should never change the behavior of
> existing features.
Yup, I misunderstood that part of your original email. Makes perfect se
This sounds great! Communicating using a well-defined JSON spec sounds
like a better idea than trying to communicate using protobufs. One
thing I would suggest is having a protocol version number in there
somewhere so the generator knows what version it's targeting.
--Pete
On Wed, Oct 28, 2009 a
On Fri, Sep 25, 2009 at 1:28 PM, dound wrote:
> 1) An option to prefix a length field to each message. This would
> make it possible to serialize/deserialize a stream of bytes (e.g., a
> TCP socket).
This is sort of out of scope of what protobuf does. It should be
handled by whatever RPC framew
n't C++ support the same
> methods as C#? The only document that I've seen that has list of
> methods available is the message.h header file, installed into my
> Linux usr directory.
>
>
> On Aug 24, 4:05 pm, Peter Keen wrote:
>> You sort of have to roll your own
about:
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.io.coded_stream.html#CodedInputStream.Limit.details
--Pete
>
>
> On Aug 24, 4:05 pm, Peter Keen wrote:
>> You sort of have to roll your own. In my project I'm doing something like
You sort of have to roll your own. In my project I'm doing something like this:
coded_output->WriteVarint32(message->ByteSize());
message->SerializeToCodedStream(coded_output);
And then on the reading side:
uint32_t size;
if (! coded_input->ReadVarint32(&size)) {
return NULL; // just an examp
pkgconfig files. Kenton, if you think this
is worthwhile to include in the distribution I can make a patch with a
Makefile target for the RPM.
--Pete
On Mon, Aug 17, 2009 at 5:47 PM, Peter Keen wrote:
> That's a good point. I'm only going to be distributing a few binaries
> that have
es.
>
> On Wed, Aug 5, 2009 at 3:05 PM, Peter Keen wrote:
>>
>> Hi guys,
>>
>> I was wondering if anyone out there had built an RPM spec file for
>> protobuf. I'll be needing to distribute the C++ runtime library to a
>> set of machines and I
If I understand the docs correctly has_* will return false if the
value is the same as the default, which in the case of numbers
defaults to 0.
--Pete
On Tuesday, August 11, 2009, multijon wrote:
>
> Hi,
>
> I'm seeing a strange behaviour of the protobuf library in the
> following situation:
>
Hi guys,
I was wondering if anyone out there had built an RPM spec file for
protobuf. I'll be needing to distribute the C++ runtime library to a
set of machines and I'd like to be able to chuck something in a shared
yum repo and be done with it, rather than having to copy around a
tarball or some
On 2009/07/31 23:56:40, kenton wrote:
This looks great, Kenton. Thanks for cleaning it up! The tests look
pretty decent as well. With such a small golden message you're probably
not going to see any difference between the different compression
levels, and it is just passed through to zlib so th
ult matching
> gzip's default. Thanks.
>
> On Wed, Jul 15, 2009 at 4:27 PM, Peter Keen wrote:
>>
>> It doesn't look like it has an existing interface for setting zlib
>> options. Reading through the source[1], it looks like it chooses
>> Z_BEST_COMPRESSION
urrently have a way
> to control compression parameters? If not, it probably should.
>
>
>
> On Wed, Jul 15, 2009 at 3:50 PM, Peter Keen wrote:
>
> > Hi guys,
>
> > I'm playing around with protocol buffers for a project at work and I'm
> > coming a
Hi guys,
I'm playing around with protocol buffers for a project at work and I'm
coming across a possibly weird problem. I have the following setup in
my main():
std::cerr << "creating file" << std::endl;
int fd = open("blah.repo", O_WRONLY, O_CREAT);
if ( fd == -1 ) {
std::ce
17 matches
Mail list logo
