Re: Python BuildFile functionality

Well, note that soon (hopefully in the next major release after 2.2.0 -- we actually have someone actively working on it now) the Python implementation will be able to wrap C++ classes for better performance. At that point it will probably be easy to accomplish what you want by handing off most of

Re: Python BuildFile functionality

y 90% for the better... That sounds more or less accurate, though we're still not completely sure how it will end up looking. The first priority is to make the Python API faster (without necessarily adding any new functionality), but adding access to DescriptorPool makes some sense once we

Re: 2.2.0 release candidate

I've put up 2.2.0rc2, same place: http://groups.google.com/group/protobuf/files 2009/8/7 Kenton Varda > Good points. I wasn't a big fan of this change in the first place but > apparently it was a big performance win on Android (which does not have a > very advanced garba

Re: top bits, compatibility & future proofing

Frankly, negative numbers shouldn't be encoded as varints at all. It's only for historical reasons that we do it. If the last byte were 0x7f, that only gets you to 70 bits, so I'm not sure how you could go from there to arbitrarily large numbers. On Mon, Aug 10, 2009 at 10:05 AM, rog wrote: > >

Re: Protobuf usage with HTTP

We do not define any particular conventions for using protobufs over HTTP. It's up to the app to decide what headers it needs and to publish those requirements. I don't see any reason to treat a protocol buffer any differently from any other sort of binary payload, though. On Mon, Aug 10, 2009 a

Re: 2.2.0 release candidate

The release is requiring copious amounts of yak shaving to get working on all platforms simultaneously. Sigh. There should be an rc3 tonight or tomorrow, followed by a final release a day later, hopefully. 2009/8/7 Kenton Varda > I've put up 2.2.0rc2, same place: > http://groups

Re: 2.2.0 release candidate

rc3 is up. Blah. If it works on both Sun Studio *and* Windows, it has to work on everything, right? On Mon, Aug 10, 2009 at 6:20 PM, Kenton Varda wrote: > The release is requiring copious amounts of yak shaving to get working on > all platforms simultaneously. Sigh. > There should

Re: Visual studio 2008 support

Yes, MSVC projects are located in the "vsprojects" folder in the source code distribution. On Tue, Aug 11, 2009 at 9:50 AM, Shri wrote: > > Does protocol buffer support Visual studio 2008 > > Thanks > Shridhar > > > --~--~-~--~~~---~--~~ You received this message

Re: Error with has_field method in C++, protobuf 2.1.0

On Tue, Aug 11, 2009 at 9:36 AM, Peter Keen wrote: > > 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. That is not correct. has_* returns true if the value was explicitly set, false if not, regar

Re: Error with has_field method in C++, protobuf 2.1.0

In your C++ code, are you storing the message as a NUL-terminated string (i.e. as char*)? Protocol Buffers are arbitrary byte arrays and may contain NULs, so this won't work. You must either store the message in a std::string or you must keep track of the length of the message separately. On Tue

2.2.0 release is up

http://code.google.com/p/protobuf/downloads/list 2009-08-11 version 2.2.0: C++ * Lite mode: The "optimize_for = LITE_RUNTIME" option causes the compiler to generate code which only depends libprotobuf-lite, which is much smaller than libprotobuf but lacks descriptors, reflection, an

Re: 2.2.0 release is up

Documentation updates have also been submitted and will be live in an hour or two. On Tue, Aug 11, 2009 at 6:46 PM, Kenton Varda wrote: > http://code.google.com/p/protobuf/downloads/list > > 2009-08-11 version 2.2.0: > > C++ > * Lite mode: The "optimize_for = LITE

Re: 2.2.0 release is up

On Wed, Aug 12, 2009 at 9:49 AM, Kenton Varda wrote: > >> Documentation updates have also been submitted and will be live in an hour >> or two. >> >> >> On Tue, Aug 11, 2009 at 6:46 PM, Kenton Varda wrote: >> >>> http://code.google.com/p/protobuf/downloa

Re: Error with has_field method in C++, protobuf 2.1.0

be happy to provide a sample file for anyone who's interested in > > trying to Parse a message for themselves. > > > > Jon > > > > On Aug 11, 10:03 pm, Kenton Varda wrote: > > > > > > > > > In your C++ code, are you storing the messa

Re: How can I serialize/deserialize my own string?

On Tue, Aug 11, 2009 at 8:15 PM, Yingfeng wrote: > > Hi, > As is known to lots of people, std::string performs not good for such > reasons as copy-on-write,... etc. Note that the C++ protobuf implementation generally assumes that string copies are expensive and avoids them as much as possible -

Re: How big is protocol buffers?

Well there's good news and bad news. The bad news is that using protocol buffers has been known to lead to large code footprints. The good news is that it should be fairly easy to estimate how much it will bloat *your* binary, without having to actually implement the whole system. Protocol buffer

Re: How big is protocol buffers?

y trying to > produce proto file for a portion of our interface, and see how that > compares. > > You don't happen to have a WSDL to proto file converter by any > chance? ;-) > > On Aug 12, 10:56 pm, Kenton Varda wrote: > > Well there's good news and bad news.

Re: How big is protocol buffers?

On Wed, Aug 12, 2009 at 3:27 PM, Noel Fegan wrote: > You don't happen to have a WSDL to proto file converter by any > chance? ;-) No, but I bet you could write an XSLT to do it pretty easily. > > > On Aug 12, 10:56 pm, Kenton Varda wrote: > > Well there's g

Re: protobuf HPUX support

Please send a patch. Use "diff -u" to create it (see the man page), or if you made your changes against the SVN sources, just use "svn diff". On Wed, Aug 12, 2009 at 10:08 PM, COFF wrote: > > Hello Kenton! > > I succesfully merge my project on new version of protobuf. > I made patches that enab

Re: Recursive import problem

Sorry, but mutually recursive messages must be declared in a single file. It would be excessively complicated to support cyclically dependent files under the current implementation. On Thu, Aug 13, 2009 at 11:34 AM, Justin Muncaster < justin.muncas...@gmail.com> wrote: > > I have the following m

Re: Protobuf-lite and ParseFromIstream/SerializeToOstream

Deciding exactly where to draw the line for lite mode was hard -- different users want different things. There's two reasonable options here: 1) Read the entire istream to a string first, then call ParseFromString. Similarly, when writing, use SerializeToString() then write the entire string to t

Re: protobuf HPUX support

Compiller Error on non const std::string) > > On 14 авг, 02:24, Kenton Varda wrote: > > Please send a patch. Use "diff -u" to create it (see the man page), or > if > > you made your changes against the SVN sources, just use "svn diff". > > >

Re: Endian

The encoding documentation: http://code.google.com/apis/protocolbuffers/docs/encoding.html specifies that fixed-width numbers are encoded in little-endian order. However, you only have to know that if you are writing a protobuf parse

Re: Core Dump with c++ 4.1.1

I assume that when you say "C++ 4.1.1", what you mean is "G++ 4.1.1", i.e. GCC 4.1.1's C++ compiler? Or do you mean some other compiler? C++ itself does not have version numbers. I have tested protocol buffers on many different versions of GCC, including both the 3.x and 4.x range. It seems very

Re: protobuf HPUX support

idual agreement via the web page. Let me know when you've signed and I'll submit this. 2009/8/13 COFF > > New patch avoid this sent. > On 14 авг, 10:54, COFF wrote: > > Thank you for answer. I will try doing this way too. > > > > On 14 авг, 10:18, Kenton V

Re: combine protobuf messages

On Fri, Aug 14, 2009 at 1:18 PM, George Georgiev wrote: > 1. How to serialize parts from the message without validation > Use the "Partial" serialization and parsing methods, e.g. SerializePartialToString() and ParsePartialFromString(). These do not check required fields. > 2. How to combine

Re: combine protobuf messages

> more information what you mean. > > Thanks > -George > > -- > *From:* Kenton Varda [mailto:ken...@google.com] > *Sent:* Friday, August 14, 2009 2:01 PM > *To:* George Georgiev > *Cc:* Protocol Buffers > *Subject:* Re: combine protobuf m

Re: Decoding protocol buffer messages from descriptor sets

This is something I intended to do with descriptor sets but haven't had time. Basically I think you should be able to specify descriptor set files in the place of directories in the import path (with -I). You are the first person to comment on it. :) Implementing this will require some refactori

Re: [HELP]How to compile protobuf with stlport on windows/MSVC ?

Feel free to send me a patch updating the #ifdefs to properly handle stlport. It looks like stlport follows the SGI interface for hash_map, so just using the non-MSVC code path should do the trick. I think only hash.h and maybe descriptor.cc would need to be updated. On Sat, Aug 15, 2009 at 8:40

Re: Fix compile error due to string literal overflow on large proto files.

It looks like you updated your compiler but didn't update the runtime library. They have to be kept in sync. Anyway, this change went into 2.2.0 which I released last week. I had a coworker review it since you weren't around. On Mon, Aug 17, 2009 at 11:40 AM, wrote: > On 2009/08/03 22:53:24, k

Re: RMI Performance Tests

What version of protocol buffers are you using? If it's 2.0.3 or previous then you need to put this line in your proto files: option optimize_for = SPEED; In 2.1.0 and up, this is the default. On Mon, Aug 17, 2009 at 10:29 AM, Tai wrote: > > Hi, > > I did some simple test to compare Java vs.

Re: RMI Performance Tests

proaches. On Mon, Aug 17, 2009 at 12:48 PM, Tai wrote: > > I am using 2.1.0 and as shown above the proto file uses option > optimize_for = SPEED; > > On Aug 17, 8:56 pm, Kenton Varda wrote: > > What version of protocol buffers are you using? If it's 2.0.3 or > prev

Re: combine protobuf messages

On Mon, Aug 17, 2009 at 10:21 AM, George Georgiev < georgi.georg...@citrix.com> wrote: > Thanks, > > Everything looks good now, except default values. I love the fact that if > the default value is explicitly stored in the message it override the base > value, and it doesn't if it is not. Am I ri

Re: RPM Spec File

FWIW, one way to make your life a lot easier might be to statically link against libprotobuf. That way you do not need to distribute anything, 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 statica

Re: References to Remote Message Objects

I've actually worked on something like that recently, but tied to a particular use case. I think you'll find it pretty hard to solve the problem in a completely general-purpose way, unless you end up writing a code generator of some sort. In order to hide the UIDs from the app, you will need to h

Re: protobuf HPUX support

l try doing this way too. > > > > On 14 авг, 10:18, Kenton Varda wrote: > > > > > Instead of changing everything that calls EXPECT_EQ on strings, can we > > > change the implementation of EXPECT_EQ itself so that doesn't trigger > this > > > erro

Re: RMI Performance Tests

but I doubt that PB will get any > close to Java's total performance (serialization, deserialization and > object creation). > > I was hoping to give our RMI environment a boost but I doesn't look > like this. I will give it another chance. > > Tai > > > On

Re: Installation requirements and supported platforms?

In theory it should work on any modern unix. In practice it's hard to say what platforms may have quirks that cause problems. I test each release on Linux, Visual Studio, Cygwin, MinGW, and Mac OSX, and Monty Taylor has been testing on Solaris with Sun Studio. It probably works on other platform

Re: Mismatch in output of TextFormat between Java and C++, for Double field

The original value is being preserved. It's just being formatted differently. The TextFormat parser knows that the field is a double even if it sees only "10". On Tue, Aug 18, 2009 at 3:11 PM, ajoy wrote: > > Hi > > I'm creating a Message in Java, with a double field in it . i set it > to "10.

Re: RPM Spec File

The problem with these spec files is that they're large and complicated and I just don't have time to learn how they work and maintain them. If someone would like to commit to maintaining these things -- which means I'd call on you to update them for each release, answer questions about them, etc.

Re: Mismatch in output of TextFormat between Java and C++, for Double field

On Tue, Aug 18, 2009 at 4:18 PM, ajoy wrote: > Is there any way to make it print "10.0" ? No. Why do you need it? > > > On Aug 18, 3:34 pm, Kenton Varda wrote: > > The original value is being preserved. It's just being formatted > > differently. The

Re: RMI Performance Tests

> 9287 nanosecs > > Based on that PB seems to be slower and I am not coming to the same > conclusion as stated in other performance tests?! > > Tai > > > > On Aug 17, 11:24 pm, Kenton Varda wrote: > > A message with three primitive fields should only take a co

Re: message field getter/Java method collision

This is a real issue. The easiest solution is not to name the field "class". A more complicated solution would be to modify the Java code generator so that it detects when a field is named "class" and somehow renames it (e.g. adds an underscore to the end). There are a very large number of ways

Re: Additional language

I'd like to add this to the list, but I noticed that the wiki page is an HTTPS link to a site with an invalid SSL certificate. I tried to change the protocol to just HTTP but the site automatically redirects to HTTPS. Modern browsers complain very loudly about this, and I feel weird posting a lin

Re: RPM Spec File

On Wed, Aug 19, 2009 at 10:47 AM, Kevin Deldycke wrote: > BTW, should we continue packaging-related discussion of protobuf here ? > Please do. > Is this issue worth a bug report ? Well, I haven't observed this problem on other platforms or distros. What happens if you write a very basic pro

Re: optimize_for = LITE_RUNTIME and DebugString() / ShortDebugString()

Makes sense. I'm happy to accept a patch along these lines. On Tue, Aug 18, 2009 at 11:12 PM, Oliver Jowett wrote: > > While experimenting with LITE_RUNTIME I noticed that the C++ methods > DebugString() and ShortDebugString() are only present on Message, not > MessageLite. > > I understand that

Re: Building without RTTI support causes "make check" to hang (recursive call to pthread_once?)

Sigh. More bugs in descriptor bootstrapping, eh? The problem is that without RTTI, MergeFrom(const Message& other) cannot tell if "other" is actually the exact same class as "this", so it has to fall back to reflection... but reflection does not work if descriptors aren't available... and we're

Re: Installation requirements and supported platforms?

The source code generated by protoc is identical regardless of what platform protoc itself is executed on. The runtime library is always required. The Java code (and the Python code, and probably Perl too though that's a third-party implementation) is completely platform-neutral so it should work

Re: Any protocol buffers MIME types?

Nope, there hasn't been any off-list discussion. Personally I have no opinion on the matter since it doesn't affect anything that I do with protocol buffers. However, the Google Wave people -- who are developing an open-source protocol that will use protocol buffers -- seem to care about this and

Re: missing parseFrom(...) variants in generate Java code; and how to build your own parseFrom() equivalent

On Tue, Aug 18, 2009 at 6:55 PM, Oliver Jowett wrote: > > Hi > > Using 2.2.0, the compiler doesn't seem to be generating Java code for > the parseFrom(byte[],int,int) and > parseFrom(byte[],int,int,ExtensionRegistryLite) static methods. Did it ever generate those methods? I don't remember if it

Re: Additional language

cate (CA Cert Signing Authority) - it > > certainly isn't in my trusted set of root certificates... > > > > On Aug 19, 3:50 am, opticron wrote: > > > > > It is a CACert certificate that is valid until May of 2010. > > > > > On Aug 18, 7:46 pm, Kent

Re: (Java) Message.Builder build()/clear()

On Wed, Aug 19, 2009 at 3:00 PM, pwr wrote: > In 2.1, one could build() multiple objects in sequence, with the same > builder object, by clear()ing it repeatedly. No, you couldn't, at least according to the docs. > In 2.2, attempting this throws an exception -- from what I can tell a > builde

Re: missing parseFrom(...) variants in generate Java code; and how to build your own parseFrom() equivalent

rried that adding so many methods is probably leading to binary bloat. On Wed, Aug 19, 2009 at 5:18 PM, Oliver Jowett wrote: > Kenton Varda wrote: > > On Tue, Aug 18, 2009 at 6:55 PM, Oliver Jowett > <mailto:oliver.jow...@gmail.com>> wrote: > > > > > > Hi &

Re: Java test failure

According to a google search for "maven skip tests", you can skip them by specifying "-Dmaven.test.skip=true" on the command line. Of course, it would be nice to know why the tests are failing. Can you send us the test result reports mentioned in the error log? On Thu, Aug 20, 2009 at 7:19 AM, Je

Re: field ordering

In practice we're talking on the order of a 10% performance gain from this optimization. So, it's not the end of the world if you write fields out-of-order. However, some users may rely on canonical ordering for other reasons, e.g. to be able to cryptographically sign messages, use their hashes a

Re: Java test failure

"); } Can you let me know if this works? On Fri, Aug 21, 2009 at 3:10 AM, Jesper Eskilson wrote: > On Fri, Aug 21, 2009 at 10:19 AM, Jesper wrote: > > > > > > > > On Aug 20, 9:56 pm, Kenton Varda wrote: > >> According to a google search f

Re: Notes on building a 64-bit install on Solaris 10 x86

I'm pretty sure #1 is not protobuf's fault. I've never heard of libgcc_s which means it's probably something GCC links against implicitly. And anyway, if libwhatever.so.1 exists, there should always be a libwhatever.so symlink to it... right? Monty, can you comment on #2? On Fri, Aug 21, 2009 a

Re: 2.2.0 "make check" failures on Solaris 10 sparc32 (problems with zlib?)

Run configure --without-zlib to disable zlib support. Alternatively, fix it and send me a patch. :) On Fri, Aug 21, 2009 at 8:44 PM, Oliver Jowett wrote: > > Oliver Jowett wrote: > > > The tests start failing here: > > > >> [--] 14 tests from IoTest > >> [ RUN ] IoTest.ArrayIo > >>

Re: Protocol Buffers and pretty print

message->DebugString() is a shortcut that returns a string representation of the message. On Fri, Aug 21, 2009 at 9:06 PM, Saptarshi wrote: > > Hello, > I'm new to using Protocol Buffers and am debugging my program. > Is there a way to pretty print a Message? (I'm new to C++ too and have > tried

Re: 2.2.0 "make check" failures on Solaris 10 sparc32 (problems with zlib?)

(Is it just the gzip/zlib tests that are broken? Nothing else in the library should depend on the zlib stuff.) On Sat, Aug 22, 2009 at 11:13 AM, Kenton Varda wrote: > Run configure --without-zlib to disable zlib support. Alternatively, fix > it and send me a patch. :) > > >

Re: optional bytes vs repeated bytes

In C++, "bytes" fields are stored using std::string. This class has a size() method which returns the length of the string. So, the length of sdata1 is: message.sdata1().size() So you want to use option (A). You would use option B if you wanted to store multiple independent byte strings, each o

Re: A quick question regarding writing protobuf message to Stream preceded by Header

Generally the most efficient way to serialize a message to stdout is: message.SerializeToFileDescriptor(STDOUT_FILENO); (If your system doesn't define STDOUT_FILENO, just use the number 1.) If you normally use C++'s cout, you might want to write to that instead: message.SerializeToOstream(st

Re: optional bytes vs repeated bytes

size method. I was > thinking of strlen on c_str() which would have given me the wrong > number of bytes. > Nice and clean now. > Regards > Saptarshi > > > On Mon, Aug 24, 2009 at 3:21 PM, Kenton Varda wrote: > > In C++, "bytes" fields are stored using std

Re: Additional language

Maybe you should move your project to code.google.com? You wouldn't have to host your SVN on (apparently) your own machine that way. Anyway, I've added a link to your wiki page. On Mon, Aug 24, 2009 at 8:09 PM, opticron wrote: > > Good news! It looks like I convinced the webmaster to poke at th

Re: C++ compilation errors when using extensions

You mean MutableExtension()? Yes, you can't use SetExtension() on message-typed extensions because regular fields of message type don't have a set_foo() accessor. So, you must use MutableExtension() instead. On Tue, Aug 25, 2009 at 5:34 AM, Jesper Eskilson wrote: > > On Tue, Aug 25, 2009 at 10

Re: Parsing messages in C++ with extensions

In C++ all compiled-in extensions are automatically registered in a global registry which is used automatically by all compiled-in classes. I now regret this design decision due to a number of subtle problems it creates, but for you it means that you don't have to do anything special. On Wed, Aug

Re: Parsing messages in C++ with extensions

wish we had an explicit ExtensionRegistry in C++... Otherwise, I don't know what your problem might be. If you can narrow it down to a small self-contained example I could debug it. On Wed, Aug 26, 2009 at 3:04 PM, Jesper Eskilson wrote: > On Wed, Aug 26, 2009 at 10:38 PM, Kenton Varda wrote:

Re: Using Message::ParseFromBoundedZeroCopyStream() over network streams

What version are you using? I thought 2.2.0 fixed this. On Tue, Aug 25, 2009 at 7:37 AM, Srinivas G wrote: > > Currently Message::ParseFromBoundedZeroCopyStream() doesn't guarantee > that it will never attempt to read beyond the specified size. > > I have seen cases where a Next() is issued on

Re: meta data in the message

import "google/protobuf/descriptor.proto" message SelfDescribingMessage { required google.protobuf.FileDescriptorSet descriptor_set = 1; required string type_name = 2; required bytes data = 3; } If you have a FileDescriptorSet, you can (in C++) construct a SimpleDescriptorDatabas

Re: How to write a protocol buffer message which correspond to java.util.Map

I'd recommend the array-of-pairs method because the parallel-arrays method leaves you open to bugs where if the arrays aren't the same size and your code doesn't carefully check for this, it could easily end up crashing due to out-of-bounds accesses. This could be a security problem. Stick with a

Re: Parsing messages in C++ with extensions

n anywhere, then the only reason to force it to be linked in is if you want it to appear correctly when using reflection or TextFormat. Otherwise you should just let it go into the UnknownFieldSet. On Thu, Aug 27, 2009 at 2:17 AM, Jesper Eskilson wrote: > On Thu, Aug 27, 2009 at 12:18 AM, Kento

Re: Is there a maven mojo to create a protocol buffer file

[+gak, who was working on a Maven plugin once upon a time] On Thu, Aug 27, 2009 at 12:33 PM, rajesh wrote: > > > Hi All, > Right now I use the following command line command as > given in the documentation to create proto files . The command is : > > > protoc -I=$src --java_out=$des

Re: A quick question regarding writing protobuf message to Stream preceded by Header

shows that you spend a lot of time in protobuf code. On Thu, Aug 27, 2009 at 7:18 PM, Kenton Varda wrote: > > > On Thu, Aug 27, 2009 at 2:06 PM, Saptarshi Guha > wrote: > >> Hello >> I was thinking about this and had some questions >> >> On Mon, Aug 24, 2

Re: Different performance results: Buffered Streams vs. Byte Streams

Did you try what I suggested before -- serializing to a byte array instead, and then writing that to the stream all at once? It's possible that ObjectOutputStream itself is just really slow, but that when using native Java serialization it uses special, highly-optimized code paths. On Thu, Aug 27,

Re: A quick question regarding writing protobuf message to Stream preceded by Header

On Thu, Aug 27, 2009 at 2:06 PM, Saptarshi Guha wrote: > Hello > I was thinking about this and had some questions > > On Mon, Aug 24, 2009 at 3:29 PM, Kenton Varda wrote: > > Generally the most efficient way to serialize a message to stdout is: > > message.S

Re: Different performance results: Buffered Streams vs. Byte Streams

ou assume Java is doing some optimization? > > On Aug 28, 4:05 am, Kenton Varda wrote: > > Did you try what I suggested before -- serializing to a byte array > instead, > > and then writing that to the stream all at once? > > It's possible that ObjectOutputStream itsel

Re: Is there a maven mojo to create a protocol buffer file

ad to review patches as well. > > http://code.google.com/p/protobuf/source/browse/#svn/branches/maven-plugin > > On Thu, Aug 27, 2009 at 9:06 PM, Kenton Varda wrote: > > [+gak, who was working on a Maven plugin once upon a time] > > > > On Thu, Aug 27, 2009 at 12:33 PM, raj

Re: Parsing messages in C++ with extensions

i, Aug 28, 2009 at 1:28 AM, Kenton Varda wrote: > > Yep, it's a very annoying problem. The solution I prefer is to add a > dummy > > usage of one of the classes in your .proto somewhere high-up in your > > program, in a place that should logically "know" th

Re: A quick question regarding writing protobuf message to Stream preceded by Header

> > Thanks for your input, it was really helpful. > Regards > Saptarshi > > On Thu, Aug 27, 2009 at 10:19 PM, Kenton Varda wrote: > > BTW, when I talk about one thing being more efficient than another, it's > > really a matter of a few percent difference. For the

Re: 2.2.0 "make check" failures on Solaris 10 sparc32 (problems with zlib?)

/code.google.com/legal/corporate-cla-v1.0.html -- If your employer does. On Sat, Aug 22, 2009 at 6:46 PM, Oliver Jowett wrote: > Kenton Varda wrote: > > Run configure --without-zlib to disable zlib support. Alternatively, > > fix it and send me a patch. :) > > I took a l

Re: Valgrind reports

Did you call ShutdownProtobufLibrary() before exiting the process? On Fri, Aug 28, 2009 at 12:05 PM, bgg wrote: > > I'm using the C++ interface for protocol buffers. In my code I don't > declare any protocol buffers objects on the stack. I have pointers to > them declared. I have built the pr

Re: Documentation bug in Encoding Section

Note that "field number" means the number you assign to the field in the .proto file, whereas "tag" means the bytes that come before the field value in the encoded message. You left-shift the field number to make the tag, and right-shift the tag to get the field number. On Fri, Aug 28, 2009 at 12

Re: trouble with NewCallback (C++)

The problem is that the parameter binding that you are providing has type DummyResponse* but the method you are trying to bind takes const DummyResponse*. Even though the former is implicitly convertible to the latter, the compiler will not consider this when selecting a template overload. The so

Re: proto with java & c++ & python

C++ Protocol Buffers use UTF-8 for all text encoding, regardless of platform. If you want to use some other encoding in your code, you will have to manually convert between that and UTF-8 when interacting with Protocol Buffers. In Java and Python everything is taken care of automatically, since th

Re: Example produces error.

Thanks for fixing the docs, Henner. On Sat, Aug 29, 2009 at 6:59 PM, Henner Zeller wrote: > And yeah, documentation needs to be fixed. > > On Aug 28, 2009 1:35 PM, "Omnifarious" wrote: > > > An example from > http://code.google.com/apis/protocolbuffers/docs/proto.html > produces an error when

Re: warnings compiling generated code on Snow Leopard

What compiler flags are you using? Since you were able to compile libprotobuf itself, I assume you have turned on additional warnings for your own project? On Mon, Aug 31, 2009 at 3:26 PM, Joshua Haberman wrote: > > I just installed Snow Leopard, which ships with: > > $ gcc --version > i686-appl

Re: warnings compiling generated code on Snow Leopard

I'm OK with a patch that just adds the call to Message(). I'm not OK with a patch that explicitly initializes every single field, which is what Michael is talking about, since it conflicts with an optimization we did to reduce code size. I'd also rather not add an option for this because it would

Re: Compiling protobuf for cross-compiling environment

Use the --with-protoc option to configure to tell it to use a particular protoc binary when building (rather than attempt to execute the one it just built). Other than that, cross-compiling works the same as with any automake/autoconf package. E.g. I have cross-compiled Windows binaries on a Mac m

Re: Compiling protobuf for cross-compiling environment

fter having a quick > look > on configure and the generated Makefile. Or will the --with-protoc > option > have this effect? > > WBR > Günther > > On 1 Sep., 18:25, Kenton Varda wrote: > > Use the --with-protoc option to configure to tell it to use a particular > >

Re: Trying to read in a proto file programatically

You haven't mapped any directories into the import search path. Read the docs for DiskSourceTree. On Wed, Sep 2, 2009 at 11:00 AM, Vainstah wrote: > > Hello Proto devs, > > I am trying to load a protocol file and am using the Importer object > (from importer.h). I am using visual studio 2008 an

Re: Parsing messages in C++ with extensions

You want: const UnknownFieldSet& set = cmd.GetReflection()->GetUnknownFields(cmd); On Thu, Sep 3, 2009 at 4:18 AM, Jesper Eskilson wrote: > On Fri, Aug 28, 2009 at 6:42 PM, Kenton Varda wrote: > > > To answer your specific question, BTW, yes, you can inspec

Re: Any progress on the Maven plugin?

[+gak] On Thu, Sep 3, 2009 at 1:47 AM, Bjorn Borud wrote: > > hi, > > someone checked in a maven plugin earlier this year. are there any > plans to make this available through a Maven repository? > > (in the process of adopting Maven, so not entirely sure how I can > contribute at the moment)

Re: Parsing messages in C++ with extensions

BTW, this also works, assuming cmd is a protoc-generated class: const UnknownFieldSet& set = cmd.unknown_fields(); On Thu, Sep 3, 2009 at 9:56 AM, Kenton Varda wrote: > You want: > const UnknownFieldSet& set = cmd.GetReflection()->GetUnknownFields(cmd); > > > On T

Re: Parsing messages in C++ with extensions

On Sun, Sep 6, 2009 at 9:46 AM, Jesper Eskilson wrote: > On Thu, Sep 3, 2009 at 6:56 PM, Kenton Varda wrote: > > You want: > > const UnknownFieldSet& set = > cmd.GetReflection()->GetUnknownFields(cmd); > > Ok, so if I have function which receives a message whic

Re: A quick question regarding writing protobuf message to Stream preceded by Header

Sorry, it's actually SerializeWithCachedSizesToArray(). It's defined on the MessageLite interface so every protocol message object has this method. On Mon, Sep 7, 2009 at 7:03 AM, Dave W. wrote: > > > To allocate a correctly-sized array and > > serialize to it wi

Re: Performance Observations using protocol and java serialization

Since you haven't provided any code it's hard to speculate on what may be going wrong. On Wed, Sep 9, 2009 at 3:01 PM, rajesh wrote: > > > Hi All, > I ran some performance tests to compare the performance for > serializing-persisting-retrieving-desirializing of my POJOs and was > really

Re: Performance Observations using protocol and java serialization

eally clumsy > if I post the code here..lemme email it to you..can you please provide > me youremail address to which I can send the code to. I have a > 'ken...@google.com' on your profile , do you want me to email it to > this id. > > > On Sep 9, 7:45 pm, Kenton Var

Re: proto with java & c++ & python

On Thu, Sep 10, 2009 at 12:51 AM, SuKai wrote: > In this page > http://code.google.com/intl/zh-CN/apis/protocolbuffers/docs/cpptutorial.html, > "Parsing and Serialization" section, > > * |bool SerializeToString(string* output) const;|: serializes the > message and stores the bytes in the gi

Re: Performance Observations using protocol and java serialization

Kent I did bench mark only those steps(parsing and serialization > > withthe size of encoded message), the code is not all that vast just > > dint want to paste it here due to readability issues..will email it > > to your account..Thanks a lot for your response kent > > > >

Re: protoc feature question

On Thu, Sep 10, 2009 at 4:36 PM, Henner Zeller wrote: > > Hi, > On Thu, Sep 10, 2009 at 4:26 PM, George Georgiev > wrote: > > Sure, but it is really hard for me to prepare something general since the > java output files are located in a different folders based on the package > specified in the p

<    3   4   5   6   7   8   9   10   11   12   >