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

there better way to do that? If not based on your experience which you will prefer? Thanks, George -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from

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

specific protocol buffer messages that represent the exact argument list per method, but this looks over kill for me. Thank you again, George On Nov 16, 12:28 pm, Henner Zeller wrote: > You might want to look into extensions that allow to do this in a > typesafe manner. >  http://code.g

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

. Thanks, George -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options,

[protobuf] message forward declaration

? In my opinion having a single proto file self-sufficient even in case it actually refers messages from other proto files could significantly simplify the build process. What the protobuf community thinks about this? Thanks, George -- You received this message because you are subscribed to the

[protobuf] Re: message forward declaration

ifferent Command protobuf message in P1 and P2. Thanks, George On Jan 21, 12:55 pm, Jason Hsueh wrote: > There are many things that need to be read from imported .proto files to > determine if the .proto is valid, or to produce correct code. e.g.: > - need to differentiate between enum an

[protobuf] Re: message forward declaration

I agree it doesn’t make sense to deploy *.java or /.cc files. What I meant to deploy is *.h + precompiled .lib files or in java case it will be *.class packaged in a jar or similar. Anyway, just an idea. On Jan 26, 3:37 pm, Henner Zeller wrote: > On Wed, Jan 26, 2011 at 15:16, George wr

combine protobuf messages

ting parts Any other ideas? thanks, George --~--~-~--~~~---~--~~ 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 from this

RE: combine protobuf messages

messages that have the same Id. >> custom algorithm based on reflection I suppose this is what I need in this case. Could you please give me a bit more information what you mean. Thanks -George From: Kenton Varda [mailto:ken...@google.com] Sent: Friday, August 14

RE: combine protobuf messages

the explicitly stored default values. Great project. Thanks, George From: Kenton Varda [mailto:ken...@google.com] Sent: Friday, August 14, 2009 5:33 PM To: George Georgiev Cc: Protocol Buffers Subject: Re: combine protobuf messages If you can just write code specif

protoc feature question

Hi, Is there a way to tell to protoc to recompile the files only if the output files are missing or are older than the input file? Thanks, George From: protobuf@googlegroups.com [mailto:proto...@googlegroups.com] On Behalf Of Kenton Varda Sent: Thursday

RE: protoc feature question

proto files is changed It looks like my use case isn't usual, but the way I'm using protobufs involves permanent updates of the proto files. Anyway, I could live with it as is. Thanks, George From: Kenton Varda [mailto:ken...@google.com] Sent: Thursda

RE: protoc feature question

personal opinion is that the best place to handle all this is the protoc itself. -G From: protobuf@googlegroups.com [mailto:proto...@googlegroups.com] On Behalf Of George Georgiev Sent: Thursday, September 10, 2009 6:19 PM To: Kenton Varda; Protocol Buffers

RE: protoc feature question

http://www.zeroc.com/vsplugin.html From: Kenton Varda [mailto:ken...@google.com] Sent: Friday, September 11, 2009 12:18 PM To: George Georgiev Cc: Protocol Buffers Subject: Re: protoc feature question Is there precedent for other tools like protoc providing this

RE: protoc feature question

Sorry guys. Yes, I asked for something else. My bad. How exactly this will handle the problem with the different output files? From: Kenton Varda [mailto:ken...@google.com] Sent: Friday, September 11, 2009 2:59 PM To: Monty Taylor Cc: George Georgiev; Protocol

RE: protoc feature question

? From: Kenton Varda [mailto:ken...@google.com] Sent: Friday, September 11, 2009 4:17 PM To: George Georgiev Cc: Monty Taylor; Protocol Buffers Subject: Re: protoc feature question On Fri, Sep 11, 2009 at 3:25 PM, George Georgiev mailto:georgi.georg...@citrix.com>>

RE: protoc feature question

javac doesn't produce a java file - what you mean it will put it in its package subfolder? -Original Message- From: henner.zel...@googlemail.com [mailto:henner.zel...@googlemail.com] On Behalf Of Henner Zeller Sent: Friday, September 11, 2009 4:34 PM To: George Georgiev Cc: K

RE: protoc feature question

go since the protoc produces source files. -Original Message- From: henner.zel...@googlemail.com [mailto:henner.zel...@googlemail.com] On Behalf Of Henner Zeller Sent: Friday, September 11, 2009 4:45 PM To: George Georgiev Cc: Kenton Varda; Monty Taylor; Protocol Buffers Subject: Re

Re: [protobuf] Json support in protobuf 3.0.0-beta-1

I have been looking into ways in which the JsonFormat class can be used to create a TypeAdapter that can be registered with Gson. Writing out a Message object to JSON is not an issue but parsing a JSON into Message object is a challenge as Gson TypeAdapter's read method gives you a JsonReader

Re: [protobuf] Json support in protobuf 3.0.0-beta-1

That's a fair point; though it would be good to have a clean way to create a Message adapter for JSON parsers without re-implementing the functionality in JsonFormat. On Tue, Oct 6, 2015 at 6:24 PM Feng Xiao wrote: > On Tue, Oct 6, 2015 at 2:31 PM, Gesly George > wrote: > >

[protobuf] protobuf-3.0.0-beta-1 Java, protoc can not recognize imported types

Hello, I am using the released java package of protobuf-3.0.0-beta-1 (*protobuf-java-3.0.0-beta-1.zip ), * I have problem of having protoc to import and recognize a type: I have two proto fil

[protobuf] Re: protobuf-3.0.0-beta-1 Java, protoc can not recognize imported types

rs.Header", the error disappeared. it seems to me that protoc had not handled the outer class properly while importing types <https://lh3.googleusercontent.com/-KD_6dAGCJAs/VnoNrVwgYYI/AGE/t8MDkJhi19s/s1600/the-error.png> Cheers On Tuesday, December 22, 2015 at 1:18:09 PM U

Re: [protobuf] protobuf-3.0.0-beta-1 Java, protoc can not recognize imported types

rs.Header", the error disappeared. it seems to me that protoc had not handled the outer class properly while importing types <https://lh3.googleusercontent.com/-KD_6dAGCJAs/VnoNrVwgYYI/AGE/t8MDkJhi19s/s1600/the-error.png> Cheers On Wednesday, December 23, 2015 at 3:17:

[protobuf] Re: protobuf-3.0.0-beta-1 Java, protoc can not recognize imported types

it seems to me that protoc had not handled the outer class properly while importing types <https://lh3.googleusercontent.com/-KD_6dAGCJAs/VnoNrVwgYYI/AGE/t8MDkJhi19s/s1600/the-error.png> Cheers On Tuesday, December 22, 2015 at 1:18:09 PM UTC+8, George Wang wrote: > > > H

[protobuf] Can a builder automatically create *repeated* message fields as needed?

I'm just hoping I've missed something but maybe this is an unusual case and so isn't directly supported - if so fair enough :) /George -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email

[protobuf] Question about size/speed of protobufs with different formats

Hello, I was wondering which of the following ways to define a .proto would be faster / more space efficient -- or if there'd be no difference at all... Option 1: message Packet { ... repeated Process process = 6; ... message Process { optional uint32 pid = 1; ... optional s

[protobuf] Syntax error on 'src/google/protobuf/stubs/atomicops.h'

I've seen a syntax error on src/google/protobuf/stubs/atomicops.h file. The define GOOGLE_PROTOBUF_ATOMICOPS_ERROR has an error. It's not possible to define "#error" inside a define. It causes 'error: stray ‘#’ in program' compilation error. The current code put *#error "..."* inside GOOGLE