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 kind of behavior? I've never heard of such a thing. E.g. GCC does not check if the .cc file is newer than the .o file before compiling. On Fri, Sep 11, 2009 at 8:41 AM, George Georgiev georgi.georg...@citrix.commailto:georgi.georg...@citrix.com wrote: Just one more thing. I forgot to mention that the output is just one side of the coin. What about of the dependencies. If I have a proto file that includes another proto file now I need to extend the makefile to handle this too. What about if the dependencies are more complex and dynamic. My personal opinion is that the best place to handle all this is the protoc itself. -G From: protobuf@googlegroups.commailto:protobuf@googlegroups.com [mailto:protobuf@googlegroups.commailto:protobuf@googlegroups.com] On Behalf Of George Georgiev Sent: Thursday, September 10, 2009 6:19 PM To: Kenton Varda; Protocol Buffers Subject: RE: protoc feature question That seems reasonable to me. If you changed the package of any of your other Java files it would mean moving source code around which would certainly require updating the makefile. for me too, but some colleagues find this as extra pain Another idea is to have protoc output the .java files into a temporary directory, and then jar up that whole directory, and consider the .jar to be the output of the operation. That way you have just one output and it's the same regardless of the content of the .proto files. this means I will need to rebuild the whole jar file if any of the 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.commailto:ken...@google.com] Sent: Thursday, September 10, 2009 5:45 PM To: George Georgiev; Protocol Buffers Subject: Re: protoc feature question On Thu, Sep 10, 2009 at 4:59 PM, George Georgiev georgi.georg...@citrix.commailto:georgi.georg...@citrix.com wrote: So you suggest if I change the java package in a proto file, I to update the makefile too? That seems reasonable to me. If you changed the package of any of your other Java files it would mean moving source code around which would certainly require updating the makefile. Another idea is to have protoc output the .java files into a temporary directory, and then jar up that whole directory, and consider the .jar to be the output of the operation. That way you have just one output and it's the same regardless of the content of the .proto files. --~--~-~--~~~---~--~~ 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 group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
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 Buffers Subject: Re: protoc feature question On Fri, Sep 11, 2009 at 1:51 PM, Monty Taylor mord...@inaugust.commailto:mord...@inaugust.com wrote: Well, the build-if-newer is handled by either Make or VisualStudio, not by the compiler in either case. Right, the link is to a build system plugin. I'm all for build system plugins for protocol buffers but those wouldn't involve changing protoc. As for the dependencies ... gcc _does_ have options (-MD -MP -MF) to spit out depends that it determines from following include files in Makefile format. I'd definitely accept adding an option like that to protoc, if someone sends me a patch, though this is pretty different from what George was asking for. So I would be in favor of protoc including support for the second. I have no interest (and actually a negative interest) in protoc handling the first thing - that's a job for a build system) Sounds like we're in agreement here. --~--~-~--~~~---~--~~ 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 group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
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: Kenton Varda; Monty Taylor; Protocol Buffers Subject: Re: protoc feature question On Fri, Sep 11, 2009 at 4:22 PM, George Georgiev georgi.georg...@citrix.com wrote: I think that protoc already has a compromise with pure compiler functionality - namely placing the java class in the package subfolder. javac does the same: compile a java file and it will put it in its package subfolder. But javac as well lets the build system handle the dependencies. -h --~--~-~--~~~---~--~~ 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 group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
RE: protoc feature question
That seems reasonable to me. If you changed the package of any of your other Java files it would mean moving source code around which would certainly require updating the makefile. for me too, but some colleagues find this as extra pain Another idea is to have protoc output the .java files into a temporary directory, and then jar up that whole directory, and consider the .jar to be the output of the operation. That way you have just one output and it's the same regardless of the content of the .proto files. this means I will need to rebuild the whole jar file if any of the 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: Thursday, September 10, 2009 5:45 PM To: George Georgiev; Protocol Buffers Subject: Re: protoc feature question On Thu, Sep 10, 2009 at 4:59 PM, George Georgiev georgi.georg...@citrix.commailto:georgi.georg...@citrix.com wrote: So you suggest if I change the java package in a proto file, I to update the makefile too? That seems reasonable to me. If you changed the package of any of your other Java files it would mean moving source code around which would certainly require updating the makefile. Another idea is to have protoc output the .java files into a temporary directory, and then jar up that whole directory, and consider the .jar to be the output of the operation. That way you have just one output and it's the same regardless of the content of the .proto files. --~--~-~--~~~---~--~~ 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 group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
combine protobuf messages
Hi, I have a following use case and I'm not sure what will be the best way to go. I have a relatively complex protobuf message that I'm using in my application. It should be correctly initialized my application to works. The problem I have is that the information that makes this complete message is provided from several different sources. I have no control over them (how much and what information they will provide). The only requirement is at the end after all of the information is collected from all of the sources the message is full. The sources will have priorities so if there are overlaps of the information the information from the source with high priority will be used. What most probably I need is: 1. How to serialize parts from the message without validation 2. How to combine two parts. Or how to parse second part which may overlap some of the already existing 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 group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
RE: combine protobuf messages
Hi,
MergeFrom sounds good.
The only issue that I still will have is with the repeated fields. For some of
them I will have an Id attribute. So what I would like to achieve is when I
merge the messages instead of adding new partial message in the list it to
combine those of the repeated 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, 2009 2:01 PM
To: George Georgiev
Cc: Protocol Buffers
Subject: Re: combine protobuf messages
On Fri, Aug 14, 2009 at 1:18 PM, George Georgiev
georgi.georg...@citrix.commailto:georgi.georg...@citrix.com 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 two parts. Or how to parse second part which may overlap some
of the already existing parts
Use MergeFrom():
MyMessage combined;
// Iterate over messages from lowest to highest priority.
for (int priority = 0; priority max_priority; ++priority) {
combined.MergeFrom(messages_by_priority[priority]);
}
// Check
if (!combined.IsInitialized()) {
cerr Missing required fields:
combined.InitializationErrorString() endl;
return false;
}
As documented, the semantics of MergeFrom() are: Singular fields will be
overwritten, except for embedded messages which will be merged. Repeated fields
will be concatenated.
So, if you merge the highest-priority message last, then its values will end up
taking precedence.
If MergeFrom() isn't quite what you want, then you'll have to write a custom
algorithm based on reflection.
--~--~-~--~~~---~--~~
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 group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
