Re: [protobuf] Re: Licensing, again

I see. There are no pending patents either. I'm not sure why the FAQ was worded ambiguously like that. We'll get it fixed, though we'll probably have to run it by legal, so it might take a bit. On Wed, Jun 22, 2011 at 12:51 AM, John Haine wrote: > Kenton, many thanks fo

Re: [protobuf] Licensing, again

I'm not sure I understand the question. As the FAQ says, we hold no patents on this code. What is your concern, exactly? If we dual-licensed the code under BSD and Apache, would that help? On Tue, Jun 21, 2011 at 2:32 AM, John Haine wrote: > First, apologies if this question has already been a

Re: [protobuf] undefined reference to GzipInputStream

GzipInputStream is only compiled into the library if zlib is available, since it depends on zlib. On Unix you should be able to fix this by installing libz.so, on MSVC you may need to modify the project files a bit. On Wed, May 18, 2011 at 12:18 AM, Shin wrote: > I'm learning how to use the gzi

Re: [protobuf] Re: New protobuf feature proposal: Generated classes for streaming / visitors

reflection already solves most of the same problems. > > thanks > -jeff > > On Feb 8, 2:34 pm, Kenton Varda wrote: > > On Tue, Feb 8, 2011 at 5:47 AM, Evan Jones wrote: > > > > > The Visitor class has two standard implementations: "Writer" and > >

Re: [protobuf] Linker Errors and stdcall vs cdecl calling conventions (VC++ 2008)

We never actually "chose" to use cdecl; it was simply the default used by MSVC. This whole idea that the programmer should have to choose between calling conventions is a bit strange and inconvenient. The LIBPROTOBUF_EXPORT annotations are annoying enough; I hope we don't have to litter our code

Re: [protobuf] Suspected bug in java 2.4.0a Sub-builders

y to clear() immediately after getInnerBuilder(). > > I'm still mulling over the 1st issue.. There could be use cases where it is > useful; but then having a get() mark it as dirty seems a little wrong. > > Great work by the way! > > > Sent from my iPhone > > On 22 F

Re: [protobuf] Creating a FileDescriptorSet of all .proto files used in a certain executable

As you note, you can't iterate over all compiled-in protos. However, if you can collect a set of "root" protos that you care about, it's easy to traverse down the tree to collect all their dependencies. In general, trying to enumerate "everything that is linked in" tends to lead to trouble. The

Re: [protobuf] Feature request: ability to suppress logging of message fields

You can always write custom code that formats messages any way you want for your logs. The TextFormat class is based purely on public interfaces, so you can copy it and modify it. You can define a custom option for flagging fields that you want removed from the logs and use that custom option in

Re: [protobuf] Extending the compiler and programatically importing options

Nope, there's no way to do this, sorry. On Tue, Feb 15, 2011 at 4:49 AM, Arkaitz Jimenez wrote: > Hi, > I've my own compiler extension that adds some code over the standard > code generated by cppgenerator. > Now, I want to add a custom option, I know I can do that by adding the > custom option

Re: [protobuf] Number of Bits Written to Memory

Protobufs provide their own encoding. You can't control exactly how the bytes are written, unless you write your own encoder, which would defeat the purpose. On Thu, Feb 3, 2011 at 8:58 AM, Tanya wrote: > Hi, we are looking at replacing a XML/JAXB project with something > similar to protocol bu

Re: [protobuf] Circular package import problem

On Tue, Feb 8, 2011 at 4:14 AM, David Yu wrote: > Hmm, so protoc doesn't handle cyclic imports as well. > Are there plans to support it in the near future? > No, cyclic imports are not likely to be supported. Many programming languages do not support them, so supporting them in .proto would mak

Re: [protobuf] constants, enums, signed vs unsigned

Enums are signed, yes. I would suggest not defining constants in .proto files at all. There isn't really any good way of doing it. Enums really aren't designed to be used as numeric constants (especially in Java where they aren't even numeric), but default values are also a pretty awkward way to

Re: [protobuf] Error when build universal binary on Mac OS Tiger 10.4 sdk

>From the error message, it seems like GCC doesn't like being passed "/Volumes/Data/XCode/SDKs/MacOSX10.4u.sdk" in CXXFLAGS. Are you sure this is needed at all? If so, maybe this should be passed as LIBS or LDFLAGS instead? On Tue, Feb 22, 2011 at 3:50 AM, pick_tim wrote: > I tried compile pro

Re: [protobuf] Typed Array Support

Well, first we'd need a Javascript protobuf implementation. There are a couple third-party ones, but Google doesn't provide one at this time. The usual way to deal with Javascript is to encode your message in JSON, e.g. using the code provided by http://code.google.com/p/protobuf-java-format/. O

Re: [protobuf] Re: .proto file with enumeration only

Unix and Windows EOLs should work, but old-Mac EOLs (which were just '\r's with no '\n') probably will not work. I thought that Mac stopped using that style with OSX, though, so I'm not sure why you'd be seeing this problem 10 years later. On Wed, Feb 16, 2011 at 11:16 AM, dan wrote: > okay...

Re: [protobuf] Re: Why does ARMv5 thinks their are 2 implementations for these 4 functions in repeated_field.CC?

A lot of C++ compilers do not implement the (ridiculously complicated) standard correctly, especially when it comes to complex templates. If you can provide a patch which fixes your problem, we could consider adopting it, but otherwise the only advice I can give is: use GCC, Clang, or MSVC. On F

Re: [protobuf] RpcChannel and RpcController Implementation

For AppEngine you'll need to accept all incoming requests over HTTP. You probably don't want to use the RPC interfaces -- just use the regular servlet interface and use encoded protobufs in the request and response bodies. On Wed, Feb 16, 2011 at 10:39 PM, Amit wrote: > > Hi All, > > I am very

Re: [protobuf] Suspected bug in java 2.4.0a Sub-builders

The first issue is the intended behavior. It matches C++, where calling mutable_inner() instantiates the inner message. There needs to be a way to mark a sub-message "present" without actually setting any of its friends. The second issue looks genuine, although it seems to me that it would cause

Re: [protobuf] compound message allows colon

It's a "feature". This has always been allowed. No one really knows why. On Fri, Feb 18, 2011 at 9:53 AM, naderp wrote: > Hi, > > Given the following .proto definition: > > message person { > required string name = 1; > required int32 id = 2; > } > > I noticed the following message syntax

Re: [protobuf] New protobuf feature proposal: Generated classes for streaming / visitors

On Tue, Feb 8, 2011 at 11:23 AM, Evan Jones wrote: > Sorry, just an example of why you might want a different protocol. If I've > streamed 10e9 messages to disk, I don't want this stream to break if there > is some weird corruption in the middle, so I want some protocol that can > "resume" from c

Re: [protobuf] New protobuf feature proposal: Generated classes for streaming / visitors

On Tue, Feb 8, 2011 at 5:47 AM, Evan Jones wrote: > I read this proposal somewhat carefully, and thought about it for a couple > days. Thanks for the feedback! > * It seems to me that this will solve the problem for people who know > statically at compile time what types they need to handle f

Re: [protobuf] Circular package import problem

With protoc (the standard compiler), this should produce a simple error. Since Ken said he "got StackOverFlow exception", it sounds like he's using some other compiler (not written in C++). On Mon, Feb 7, 2011 at 10:26 AM, Pherl Liu wrote: > You probably need to break up your proto files to eli

Re: [protobuf] header update in building protobuf 2.4.0a on cygwin

add_person_java and list_person_java shell scripts in the examples dir. It > took me a while to figure this out > because I don't usually use cygwin for java work. > > Thanks > Jim Olson > > > > On Sun, Feb 6, 2011 at 3:33 PM, Kenton Varda wrote: > >> Wha

Re: [protobuf] header update in building protobuf 2.4.0a on cygwin

What Cygwin version? What GCC version? We do test releases on Cygwin so I'm guessing you're using an older version. The error looks like a problem that old GCCs had (though we may want to work around it). On Sat, Feb 5, 2011 at 3:59 PM, jimo555 wrote: > Just wanted to pass along a simple fix

Re: [protobuf] Re: New protobuf feature proposal: Generated classes for streaming / visitors

t; visit_baz() > > then? It's good to have some consistency. > > Frank > > > On Sat, Feb 5, 2011 at 08:06, Kenton Varda wrote: > >> On Wed, Feb 2, 2011 at 10:13 AM, Henner Zeller < >> henner.zel...@googlemail.com> wrote: >> >>> I guess th

Re: [protobuf] 2.4.0a released.

On Wed, Feb 2, 2011 at 9:59 PM, David Yu wrote: > Where the jars at? (Or do we have to build the jars from source?) > Have to build from source. (Though we're going to try to get the Maven repo updated. Long story.) > I'm trying to benchmark 2.4.0a with its java perf improvements. > The lazy

Re: [protobuf] Re: New protobuf feature proposal: Generated classes for streaming / visitors

On Wed, Feb 2, 2011 at 10:13 AM, Henner Zeller wrote: > I guess the naming is confusing in the example. The Visit is per > field-name; but since the typed is named the same as the field in this > example, it is confusing. > Yes, sorry. Better example: message MyStream { option generate_v

Re: [protobuf] Re: inheritance.. well sort of... and FieldDescriptors

You can't use the same field descriptors for the four classes. But, note that one thing you *can* do is define a "base" type that just contains the shared fields, and then parse any of the other types as this type in order to access the common fields. Since the field numbers match, they are compa

[protobuf] Re: New protobuf feature proposal: Generated classes for streaming / visitors

ould be straightforward. A Reader could allocate one object of each sub-message type for reuse. But, it seems like that wouldn't play well with ownership-passing. > > On Tue, Feb 1, 2011 at 10:45 AM, Kenton Varda wrote: > >> Hello open source protobuf users, >> >> *Backg

Re: [protobuf] Services not compiling

The *_generic_services options now default to false. You must explicitly set them to true, e.g.: option cc_generic_services = true; option java_generic_services = true; option py_generic_services = true; We decided to make these off-by-default because we want to encourage RPC implementatio

Re: [protobuf] Repeated Fields Encoding

The encoding is documented in detail here: http://code.google.com/apis/protocolbuffers/docs/encoding.html The short answer is, yes, repeated fields are literally encoded as repeated individual values, unless you use "packed" encoding

[protobuf] New protobuf feature proposal: Generated classes for streaming / visitors

Hello open source protobuf users, *Background* Probably the biggest deficiency in the open source protocol buffers libraries today is a lack of built-in support for handling streams of messages. True, it's not too hard for users to support it manually, by prefixing each message with its size as

Re: [protobuf] Re: protobuf not handling special characters between Java server and C++ client

On Tue, Jan 25, 2011 at 8:57 PM, Hitesh Jethwani wrote: > > if on the stream writer, I add something like: > > writer.write(new String(msg.getBytes(), "UTF8").getBytes()) instead of > > simply writer.write(msg.getBytes()), I see the characters as expected > > on the C++ client. However this I beli

Re: [protobuf] problems with CopyFrom(dynamic message) to generated message

They need to have exactly the same Descriptor object. When you create your DynamicMessage from the DynamicMessageFactory, pass the Descriptor object returned by the generated type's descriptor() or GetDescriptor() method. Don't construct a separate Descriptor manually. Of course, then the questi

Re: [protobuf] Problem with accents in python while unpacking a message

When using non-ASCII characters, make sure you are using the "unicode" type, not "str", to avoid any ambiguity in character encoding. Also, I vaguely remember a bug fix related to this that is in version 2.4.0, so you might try that. On Thu, Jan 20, 2011 at 10:39 AM, Louhike wrote: > Hi, > I'm

Re: [protobuf] Building Protobuffers under linux

I think if -lprotobuf wasn't found, the linker would complain about that first, rather than complain about undefined references -- unless you have some other libprotobuf in your library path which is being taken instead. Maybe an older version? On Wed, Jan 19, 2011 at 10:29 AM, Jalitt wrote: >

Re: [protobuf] Python API docs

Actually version 2.4.0 has been uploaded and is in the file list, just hasn't been marked "current" yet. That said, note that using extend() on a repeated message makes deep copies of all the message objects. Repeatedly calling add() is more efficient. On Wed, Jan 19, 2011 at 6:57 AM, Ben Ford

[protobuf] Re: 2.4.0 release candidate #1

I tested the release on MSVC 2005 and FreeBSD. Both worked fine. I also tested this on my home machine running stock Ubuntu 10.10, and I got the same error we've been seeing on our corp workstations. Thus it seems this problem is not an issue with our corp setup as I had initially thought. Inst

Re: [protobuf] best way to create message from prototype + data

Yep, that's the best thing to do right now. We're thinking of introducing a separate "Parser" interface, which would allow you to do: message = prototype.getParserForType().parse(data); On Tue, Jan 18, 2011 at 7:34 AM, koert wrote: > A very common situation for me is when i get handed a Mess

Re: [protobuf] Zig Zag Encoding (vs two's complement encoding)

The reason ZigZag encoding evolved as it did is because it can be applied as a separate layer on top of varint encoding. Originally, ZigZag was not officially part of the protobuf spec, but just something some people did manually to encode negative numbers efficiently. Eventually we made it offic

[protobuf] Re: Problem with java generation when using imports

KmObjectProtos.KmObject getKmobject() { return kmobject_; } On Wed, Jan 12, 2011 at 3:23 AM, Meghana wrote: > Thanks for the reply Kenton. > > Here's the example - > proto files : > > option java_outer_classname = "KmObjectProtos"; > > message KmO

Re: [protobuf] Re: 2.4.0 release candidate #1

On Wed, Jan 5, 2011 at 10:33 PM, Scratch wrote: > Thanks! > That's right what I needed. And one more question - will sub-builders > be introduced for lite package? > Sorry, but probably not. The whole point of the lite package is to be as small as possible, and the sub-builders stuff creates a

Re: [protobuf] Using a ByteBuffer instead of a ByteString?

On Mon, Jan 10, 2011 at 9:45 PM, Nicolae Mihalache wrote: > Hello, > > I recently started to use GPB, great software! :) > > But I have noticed in java that it is impossible to create a message > containing a "bytes" fields without copying some buffers around. For > example if I have a encoded mes

Re: [protobuf] LIBPROTOBUF_EXPORT Missing Headers

Oh, you meant that they are *not* installed. These two files are private interfaces. They have LIBPROTOBUF_EXPORT on them because libprotoc uses them. However, other clients are not meant to use these headers. On Mon, Jan 10, 2011 at 11:46 AM, Collin wrote: > The following headers have LIBPRO

Re: [protobuf] LIBPROTOBUF_EXPORT Missing Headers

OK. What is the problem? On Mon, Jan 10, 2011 at 11:46 AM, Collin wrote: > The following headers have LIBPROTOBUF_EXPORT in them but are > installed with `make install.` > > google/protobuf/stubs/strutil.h > google/protobuf/stubs/substitute.h > > -- > You received this message because you are s

Re: [protobuf] Problem with java generation when using imports

Can you provide a small, self-contained example? On Mon, Jan 10, 2011 at 7:13 AM, Meghana wrote: > Hi, > > I am using imports in my proto files. So, B has an import of A. When I > generate the java code for B, all references to A are specified as A.A > i.e. A(dot)A. It does not seem to be picking

Re: [protobuf] Re: "Truncated varint" decoding a message just built

I see, I think the encoding problem was fixed in 2.3.0. The type checker is still wrong, though. On Thu, Jan 6, 2011 at 3:17 PM, BigBaaadBob wrote: > 2.2.0a-0.1ubuntu1 > > On Dec 28 2010, 2:55 pm, Kenton Varda wrote: > > Strange. It looks like there is a bug in the type check

Re: [protobuf] Using the --proto_path option

On Tue, Jan 11, 2011 at 1:30 PM, Collin wrote: > I am trying to understand how --proto_path works. Let's say in > my .proto file have the following import lines: > import "descriptor.proto"; > import "google/protobuf/descriptor.proto"; > Delete the first of these two imports, and then use --prot

Re: [protobuf] Re: protobuffer suport composite object in stack not in heap?

does not really release the memory allocated. I can't really tell for > sure actually. > > @Kenton, does that make any sense? If yes, is there a way to avoid it? > As Evan says, this is by design. The memory is not "leaked" -- it will be reused when the message object is

Re: [protobuf] Linker issues: undefined reference to `a_message__get_packed_size'

The author of protobuf-c might not read this list. You might want to e-mail him directly. But I would suggest looking at the contents of tut.pb-c.c to see whether it actually defines a_message__pack. Maybe the problem will be obvious. On Tue, Dec 28, 2010 at 3:08 PM, Suhail Doshi wrote: > I am

[protobuf] Re: protobuffer suport composite object in stack not in heap?

I think this would be too complicated to integrate into the official C++ implementation. You could, however, write an alternative protobuf implementation that provides this. Note that with the official implementation, you can avoid malloc costs by reusing message objects. A message object never

Re: [protobuf] Re: Transfer protocol buffer object to POJO java object

Name. Is there a way to get the camel field name out? I don't > want to get the original field name name : last_name, first_name and > convert it again to camel field name every time that I want to do > getter and setter on java pojo (very inefficient). > > > Thanks, > >

Re: [protobuf] Transfer protocol buffer object to POJO java object

I don't know of any existing tools for this. You could write code that does this via reflection (protobuf reflection on the protobuf object, and basic java reflection on the POJO). Or, you could write a protoc plugin which generates the code you need, though that will be a lot more complicated.

Re: [protobuf] C# client to Java based server

Protocol buffers itself has no built-in RPC implementation. You have to find an RPC implementation that supports whatever languages you are interested in, or write your own. It's not too hard to write a simple RPC implementation given protocol buffers as a base. Sending protobufs over HTTP is a

Re: [protobuf] how can we deal with multi-lingual string? (c++)

The dirty little secret of std::wstring is that it does not actually deal with non-ASCII characters on all platforms. On some platforms wchar_t is 8-bit just like char! You should avoid using wstring and wchar_t for this reason; define your own types that are exactly what you need. For protocol

Re: [protobuf] Re: Converting JSON Text Into PB Bytes Type

t; } > > I'm using this: http://code.google.com/p/protobuf-java-format/ for > JSON <--> PB conversion > > > On Dec 23, 3:48 am, Kenton Varda wrote: > > You will probably need to base64-encode bytes fields before embedding > them > > in JSON, since JSON i

Re: [protobuf] Stronger introspection

You can use the type's descriptor to inspect the fields it contains and what all their types are. MyType.DESCRIPTOR is the descriptor for MyType. Once you've figured out what field you want to read/write, use getattr() / setattr(). Note that the C++ and Java interfaces for this are somewhat clea

Re: [protobuf] Re: "Truncated varint" decoding a message just built

ing > side doesn't complain, but the decoder does. A bug on my part, but > suboptimal behavior for the library. > > On Dec 22, 6:09 pm, Kenton Varda wrote: > > Can you provide a small, self-contained example program demonstrating > this > > problem? > > >

Re: [protobuf] "Truncated varint" decoding a message just built

Can you provide a small, self-contained example program demonstrating this problem? On Wed, Dec 22, 2010 at 4:52 PM, BigBaaadBob wrote: > I have Python code doing something like this: > > >m.whatever = somevalue; etc. >s = m.SerializeToString() >m.Clear()

Re: [protobuf] ambiguous Builder errors when compiling a Maven project

-plugin (that is reponsible for compiling both scala and > java code) gives the error messages. > > Thanks, > --Xiao > > > > On Wed, Dec 22, 2010 at 4:13 PM, Kenton Varda wrote: > > I've never seen this error. It doesn't make much sense -- protobuf &g

Re: [protobuf] Re: Reducing code size of protocol buffers

On Wed, Dec 22, 2010 at 7:58 AM, Tim Turner wrote: > This is C++. > > I had not tried optimizing for CODE_SIZE. I understood that CODE_SIZE > was the precursor to and not as compact as LITE_RUNTIME. > This is not correct. As Jason says, the generated code for CODE_SIZE is smaller, but depends

Re: [protobuf] Converting JSON Text Into PB Bytes Type

You will probably need to base64-encode bytes fields before embedding them in JSON, since JSON is a text format. Which JSON <-> protobuf converter are you using? Or did you write your own? On Tue, Dec 21, 2010 at 11:41 PM, yalmasri wrote: > Hello, > > One of our customers is still using legacy

Re: [protobuf] Reading and writing multiple messages to a file

You can only have one CodedInputStream wrapping a ZeroCopyInputStream at a time, otherwise they will confuse each other with buffering conflicts. CodedInputStreams are cheap to construct, so you can just make one on the stack in a block, like: { CodedInputStream coded_input(input_stream_p.g

Re: [protobuf] ambiguous Builder errors when compiling a Maven project

I've never seen this error. It doesn't make much sense -- protobuf generated code should not contain any imports. Are you modifying the generated code in some way? On Sun, Dec 19, 2010 at 11:47 PM, Xiao Ling wrote: > Hi All, > > I have a generated protobuf java file which compiles alone under

Re: [protobuf] Why not allow null values in Java for scalar types?

There are problems with this: 1) Boxing and unboxing primitives is relatively expensive, compared to just passing them as primitives. If performance matters to you at all (and for many protobuf users, it does), you probably don't want this. 2) If you accept messages from untrusted sources, your

Re: [protobuf] Sorting Protocol Buffers with Hadoop MapReduce

Hmm, you might want to consider parsing both messages into DynamicMessages (or into the generated message classes if you have them compiled in) and then using a protobuf-reflection-based algorithm (not to be confused with Java reflection; see Message#getField()). Your current code is very much cou

Re: [protobuf] Nullpointer Exception when .parseFrom(byte [])

Indeed, this was a bug that we fixed. On Wed, Dec 8, 2010 at 7:04 AM, jim horng wrote: > Hi Kenton, > > here are the stacktrace, i found i'm using 2.1.0 > > java.lang.NullPointerException > > at > com.google.protobuf.UnknownFieldSet$Builder.mergeField

Re: [protobuf] Allow protobuf-related job postings on this list?

(Woops, posted from the wrong account again. That was me.) On Sun, Dec 12, 2010 at 11:06 PM, Kenton Varda wrote: > Hi all, > > I received an e-mail from a recruiting company asking whether it would be > OK to post a job listing on this mailing list. Apparently, they need > some

[protobuf] Allow protobuf-related job postings on this list?

7;t know what's appropriate. It is, after all, protobuf-related. I suppose it all depends on how you -- the list members -- feel. Should I allow it? (Obviously I would still reject non-protobuf-related solicitations.) Discuss. -Kenton -- You received this message because you are subscribed

Re: [protobuf] Any Python wrappers for the C++ implementation?

On Tue, Dec 7, 2010 at 9:19 PM, Yang Zhang wrote: > > Also, note that if you explicitly compile C++ versions of your > > messages and link them into the process, they'll be even faster. (If you > > don't, the library falls back to DynamicMessage which is not as fast as > > generated code.) > > I

Re: [protobuf] "File already exists in database" on Mac OSX

I assume this is happening at startup? Is it possible that you are somehow linking two copies of the same .pb.cc into your binary? There are cases where the linker doesn't catch this, especially when dynamic linking is involved, but sometimes even with static linking. Speaking of which, are you

Re: [protobuf] Nullpointer Exception when .parseFrom(byte [])

The file you attached is not useful without source code. But what would be even better is if you could provide the stack trace for the NullPointerException. The parser should never throw NPE and I'm not aware of any bugs which cause it to throw NPE. BTW, it's very easy for bytes which are not ac

Re: [protobuf] Re: java parse with class known at runtime (and compiled proto)

Evan is correct. The best way to write code which deals with a generic protobuf type is to have it take a default instance as a parameter. From that you can do everything else. This is actually better than passing around Class objects, because it allows users to use DynamicMessages with your cod

Re: [protobuf] Preferred Citation?

something like (Bibtex): > > @MISC{protobuf, > title={Protocol Buffers}, > author={Kenton Varda}, > howpublished={\url{http://code.google.com/apis/protocolbuffers/}}, > } > > but I'm sure that the authors list is woefully incomplete. Is there a more > complete

Re: [protobuf] protobuf json codec

Hi Siju, This is pretty cool. I added it to the third-party add-ons wiki. http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns Just a minor complaint: You are not Google, so your code should not live under the com.google package. Can you please move it to a different package? Perhaps com

Re: [protobuf] Any Python wrappers for the C++ implementation?

g > > > On Wed, Dec 1, 2010 at 12:07 PM, Yang Zhang > wrote: > > Thanks Kenton, we'll take a look. Out of curiosity, any ETA on 2.4.0? > > > > On Wed, Dec 1, 2010 at 12:04 PM, Kenton Varda wrote: > >> Protobuf 2.4.0 will include an implementation of the P

Re: [protobuf] 2.4.0 and lazy UTF-8 conversions in Java

On Wed, Dec 1, 2010 at 3:33 AM, Evan Jones wrote: > The instanceof approach to switch between the two is a good idea. When I > wrote my implementation, I was concerned about the thread-safeness issues, > although I don't think I ever considered this particular version. However, I > think this can

Re: [protobuf] Any Python wrappers for the C++ implementation?

Protobuf 2.4.0 will include an implementation of the Python API that is backed by C++ objects. The interface is identical to the existing Python API, and you can wrap it around existing C++ objects or have it construct its own. This code is already is SVN. Unfortunately the team is someone backl

Re: [protobuf] Handling streaming in Python

It's better to copy the functions into your own code than to depend on internal interfaces. On Tue, Nov 30, 2010 at 10:02 PM, Gregory Szorc wrote: > You can load the _DecodeVarint and _VarintEncoder modules from > google.protobuf.internal.{decoder,encoder} if you want to risk using an > internal

Re: [protobuf] Handling streaming in Python

Unfortunately the Python library doesn't provide a nice interface for this. You have to encode/decode the leading varints by hand. However, the encoding is pretty simple, so we're talking about maybe a 5-line helper function. http://code.google.com/apis/protocolbuffers/docs/encoding.html#varints

Re: [protobuf] 2.4.0 and lazy UTF-8 conversions in Java

On Tue, Nov 30, 2010 at 1:21 PM, Evan Jones wrote: > * I'll guess that it will not be slower if you access all the strings. > Currently, the parsing process copies the raw bytes from the input buffer > into an individual byte array, then converts that to a String. This is, > sadly, the most effic

Re: [protobuf] 2.4.0 and lazy UTF-8 conversions in Java

To answer your questions: 1) It is thread-safe. 2) No locking or other synchronization overhead is involved. The string data is stored as an Object pointer which, at any particular time, may point at either a String or a ByteString. When one form or the other is requested, we convert the represen

Re: [protobuf] Encoding/Decoding extension

Seems fine to me. One point: Rather than use ListFields(), I would recommend adding a type ID field to Message, e.g.: message Message { optional int32 type_id = 1; extensions 5 to max; } Reflection is kind of annoying to use, and can be somewhat slow. On Thu, Nov 25, 2010 at 5:

Re: [protobuf] Re: python enum values option

32 AM, Vsevolod Zadubrovsky wrote: > Kenton, > > I didn't find how to attach file in the group discussion, so am replying to > you directly. > In attach you will find the source proto file, the generated *pb2.py files, > and the test program enum_test.py > I used: google prot

Re: [protobuf] [PATCH] Display non-present fields with TextFormat.

Hi Brenden, Thanks for your interest in improving protocol buffers. I can see how this option would be useful to some people. Unfortunately, there are a lot of options that different people find useful, and if we implemented all of them, we'd end up with a very boated library that no one wants t

Re: [protobuf] Re: building libprotobuf-lite for iPhone

On Tue, Nov 23, 2010 at 3:47 AM, Marcus Better wrote: > On 1 Nov, 16:39, Marcus Better wrote: > > I wonder if anyone has built libprotobuf-lite for the iOS, and if > > there are any special pitfalls? > > Yes I have, and of course I will share my findings with the world for > the benefit of manki

Re: [protobuf] Re: protocol buffer message that accepts a variety of different arguments

On Tue, Nov 16, 2010 at 1:28 PM, George wrote: > Thank you for your advice. > > I’m implementing a component model that has a different type-system > than protocol buffer. For the connectors that are IPC or inter > technology I would like to base the serialization on protocol buffers. > There is

Re: [protobuf] Parse from a iterator range possible?

I think your best bet is to construct an std::string from the iterator range, and then parse from that. STL-style iterators are awkward because they achieve polymorphism via templates. In order for the protobuf parser to be able to use arbitrary iterators directly, the whole parser would have to

Re: [protobuf] Visual Studio 2010

I test every release on MSVC (2005 and 2008; 2010 wasn't around yet when 2.3.0 was released). I did not see these problems. What version are you using? You could try downloading the latest version of gtest from googletest.googlecode.com and replacing the gtest directory with it. Note that as of

Re: [protobuf] extending enums

There is no explicit support for this. You can, of course, just use an integer instead. On Sat, Nov 13, 2010 at 8:10 AM, sabretoothedhamster < sabretoothedhams...@gmail.com> wrote: > Hello everyone! > > Is there any way to extend not only a message, but an enum also? E.g. > having the example fr

Re: [protobuf] Build error on HPUX11.11 with aCC(HP ANSI C++ B3910B A.03.37)

It's possible that aCC does not correctly implement the C++ standard. Templates are really complicated and few compilers get them completely right. Unfortunately all I can say is if you get it working, send a patch. We do not use this compiler at Google so I can't test it myself. On Fri, Nov 12

Re: [protobuf] The generated java code crashes if I try to integrate it into an Eclipse Rich Client application

The generated code contains a big string literal which contains metadata about the types. The metadata is itself a protocol buffer, and is decoded at startup. It looks like it is somehow being corrupted in your environment. I don't know how that would happen. I recently wrote an Eclipse plugin

[protobuf] Re: Swap() on Windows

On Wed, Nov 10, 2010 at 6:51 PM, Anand Ganesh wrote: > Hi Kenton, all, > > When you have a message which contains a string member variable, the > variable is initialized to a default-value. > > So you have > ::std::string *name_; > static const ::std::string

Re: [protobuf] Re: python enum values option

_handle.full_name, >extension_handle.containing_type.full_name, >message.DESCRIPTOR.full_name)) > > Any ideas ? may be it is already solved in trunk version? > > Thanks > > On Nov 10, 1:50 am, Kenton Varda wrote: > > You

Re: [protobuf] Re: omitting tag numbers

On Tue, Nov 9, 2010 at 10:42 PM, Christopher Smith wrote: > This aspect could be mostly mitigated by integrating a metadata header in > to files. For systems with this kind of an approach look at Avro & Hessian. > Problems with that: 1) Protobufs are routinely used to encode small messages of jus

Re: [protobuf] link issue with proto in different project

There is a command-line option to add an export macro to all definitions. Use something like: protoc --cpp_out=dllexport_decl=MY_EXPORT_MACRO:outdir However, be very careful when passing protobuf objects across a DLL boundary. The code on both sides must be dynamically linked against the same

Re: [protobuf] optional imports for protos

Technically, there is no such file "google/protobuf/csharp_options.proto". The canonical directory "google/protobuf" should contain only files from the official Google protobuf implementation. But it seems the C# implementation you're using has chosen to put their own file under this path. I gue

Re: [protobuf] protoc.exe for 2.2.0a

It's the same as 2.2.0. The only change in 2.2.0a affects the runtime library on Linux. On Fri, Nov 5, 2010 at 12:29 PM, Sherry wrote: > Is there a downloadable windows binary for the protoc compiler for > 2.2.0a? > > -- > You received this message because you are subscribed to the Google Group

Re: [protobuf] 'python setup.py test' failed

I haven't seen this problem, but my wild guess is that for some reason your environment is using distutils instead of setuptools. They are similar, but distutils lacks some features, such as the "test" command. I'm not sure why this would happen, though. On Tue, Nov 9, 2010 at 1:05 AM, cy wrote

Re: [protobuf] python enum values option

You need to use the descriptor for the enum type. Unfortunately this interface isn't very well fleshed-out in Python. I think you'd have to write something like: Request.DESCRIPTOR.fields_by_name['error'].enum_type.values_by_number[message.error].options.Extensions[verbose_enum_value_option] I

  1   2   3   4   5   6   7   8   9   10   >