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::cerr
a way
to control compression parameters? If not, it probably should.
On Wed, Jul 15, 2009 at 3:50 PM, Peter Keen peter.k...@gmail.com wrote:
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
, with the default matching
gzip's default. Thanks.
On Wed, Jul 15, 2009 at 4:27 PM, Peter Keen peter.k...@gmail.com 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 (-9 to the gzip command
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
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
, 2009 at 3:05 PM, Peter Keen peter.k...@gmail.com 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'd like to be able to chuck something in a shared
yum repo
, and
you do not need to distribute a new package when you update to a new version
of protocol buffers. This is the approach we take at Google -- we
statically link everything except basic system libraries.
On Wed, Aug 5, 2009 at 3:05 PM, Peter Keen peter.k...@gmail.com wrote:
Hi guys,
I
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 example.
/protocolbuffers/docs/reference/cpp/google.protobuf.io.coded_stream.html#CodedInputStream.Limit.details
--Pete
On Aug 24, 4:05 pm, Peter Keen peter.k...@gmail.com wrote:
You sort of have to roll your own. In my project I'm doing something like
this:
coded_output-WriteVarint32(message-ByteSize
doesn'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 peter.k...@gmail.com wrote:
You sort of have to roll your own. In my project I'm
On Fri, Sep 25, 2009 at 1:28 PM, dound doun...@gmail.com 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
the message type in.
--Pete
On Tue, Dec 1, 2009 at 12:13 PM, Peter Keen peter.k...@gmail.com 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 10:27 AM, David
On Wed, Jul 14, 2010 at 1:36 AM, bwp per.mal...@gmail.com 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
13 matches
Mail list logo
