Re: [protobuf] Error with Netty and extensions
On Sun, Feb 6, 2011 at 12:50 PM, Marco@worldcorp wrote: > Do i need to somehow declare extensions whenever i register my > ProtocolDecoder / ProtocolEncoder? > I don't know what ProtocolDecoder/ProtocolEncoder are, but yes, you need to provide an ExtensionRegistry to the parsing method. See http://code.google.com/apis/protocolbuffers/docs/reference/java/com/google/protobuf/MessageLite.Builder.html#mergeFrom(com.google.protobuf.CodedInputStream, com.google.protobuf.ExtensionRegistryLite) > > If i don't set any extensions, the client-server communication works > fine > > could anyone help? > > w/kindest regards > marco > > > > > > > > > > > > > -- > 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. > > -- 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: [protobuf] Re: Compilation error for ppc/440 target
Yes, this code was added in 2.4.0. On Fri, Feb 4, 2011 at 7:06 AM, dear chap wrote: > Unfortunately we have to use the particular compiler in question and > cannot upgrade. Is the > DescriptorBuilder::OptionInterpreter::AggregateOptionFinder new code ? > I dont see this problem with protobuf-2.3.0. > > -- > 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. > > -- 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: [protobuf] Re: Generate .proto file from FileDescriptor?
I'm not aware of anything in the Java library that provides this functionality. On Fri, Feb 4, 2011 at 6:45 AM, Ben Wright wrote: > Anyone know if this can be accomplished without resorting to JNI? > > On Feb 3, 4:01 pm, Jason Hsueh wrote: > > C++'s FileDescriptor::DebugString() produces text that is reparsable as a > > .proto file > > > > On Thu, Feb 3, 2011 at 12:52 PM, Ben Wright > wrote: > > > I've started a project generating new FileDescriptors at runtime in > > > Java using FileDescriptorProto in order to dynamically extend a base > > > type. > > > > > I have a class that generates .proto files (StringBuilder) and one > > > that generates FileDescriptorProto. > > > > > What I was wondering was if there was a class (in java or c++ that can > > > turn a FileDescriptor / FileDescriptorProto into a .proto text file. > > > > > -- > > > 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. > > -- > 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. > > -- 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.
[protobuf] Re: New protobuf feature proposal: Generated classes for streaming / visitors
I'm starting to look at the patch (meant to start end of last week but got caught up in other stuff) On Tue, Feb 1, 2011 at 9:30 PM, Kenton Varda wrote: > On Tue, Feb 1, 2011 at 3:17 PM, Jason Hsueh wrote: > >> Conceptually this sounds great, the big question to me is whether this >> should be implemented as an option in the compiler or as a separate plugin. >> I haven't taken a thorough look at the patch, but I'd guess it adds a decent >> amount to the core code generator. I have a preference for the plugin >> approach, but of course I'm primarily an internal protobuf user, so I'm >> willing to be convinced otherwise :-) Would using a plugin, possibly even >> shipped with the standard implementation, make this feature too inconvenient >> to use? Or is there enough demand for this that it warrants implementing as >> an option? > > > First of all, note that this feature is off by default. You have to turn > it on with the generate_visitors message-level option. The only new code > added to the base library is a couple templates in WireFormatLite, which are > of course never instantiated if you don't generate visitor code. > > There are a few reasons I prefer to make this part of the base code > generator: > > - If you look at the patch, you'll see that the code generation for the two > Guide classes actually shares a lot with the code generation for > MergeFromCodedStream and SerializeWithCachedSizes. To make this a plugin, > either we'd have to expose parts of the C++ code generator internals > publicly (eww) or we'd have to reproduce a lot of code (also eww). > > - The Reader and Writer classes directly use WireFormatLite, which is a > private interface. > > - It seems clear that this feature is widely desired by open source users. > We're not talking about a niche use case here. > > >> Regarding the proposed interfaces: I can imagine some applications where >> the const refs passed to the visitor methods may be too restrictive - the >> user may instead want to take ownership of the object. e.g., suppose the >> stream is a series of requests, and each of the visitor handlers needs to >> start some asynchronous work. It would be good to hear if users have use >> cases that don't quite fit into this model (or at least if the existing use >> cases will work). >> > > Interesting point. In the Reader case, it's creating new objects, so in > theory it ought to be able to hand off ownership to the Visitor it calls. > But, the Walker is walking an existing object and thus clearly cannot give > up ownership. It seems clear that some use cases need const references, > which means that the only way we could support ownership passing is by > adding another parallel set of methods. I suppose they could have default > implementations that delegate to the const reference versions, in which case > only people who wanted to optimize for them would need to override them. > But I'd like to see that this is really desired first -- it's easy enough > to add later. > Yeah, there's definitely a need for the const ref versions. It sounds like nobody is clamoring for mutable access/ownership-passing so let's proceed as is. > Also note that my code currently doesn't reuse message objects, but > improving it to do so would 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. > Perhaps instead of ownership-passing the methods could provide mutable access so people could Swap() etc. It would defeat the optimization, but at least be less messy. Anyway, all of this can be revisited later should the need arise. > > > >> >> On Tue, Feb 1, 2011 at 10:45 AM, Kenton Varda wrote: >> >>> 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 described here: >>> >>> >>> http://code.google.com/apis/protocolbuffers/docs/techniques.html#streaming >>> >>> However, this is awkward, and typically requires users to reach into the >>> low-level CodedInputStream/CodedOutputStream classes and do a lot of work >>> manually. Furthermore, many users want to handle streams >>> of heterogeneous message types. We tell them to wrap their messages in an >>> outer type using the "union" pattern: >>> >>> http://code.google.com/apis/protocolbuffers/docs/techniques.html#union >>> >>> But this is kind of ugly and has unnecessary overhead. >>> >>> These problems never really came up in our internal usage, because inside >>> Google we have an RPC system and other utility code which builds on top of >>> protocol buffers and provides appropriate abstraction. While we'd like to >>> open source this code, a lot of it is large, somewhat messy, and highly >>> interdependen
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 eliminate the circular > dependency.. (i.e. have multiple .proto files for a package, and only import > necessary .proto files). > > > On Mon, Feb 7, 2011 at 5:42 PM, Ken wrote: > >> Hi, >> >> I have two proto files: A.proto and B.proto. If I import package B in >> A and import A in B, I got StackOverFlow exception during compiling. >> Does anyone know any sulotion for it? >> >> Thanks, >> >> Ken >> >> -- >> 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. >> >> > -- > 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. > -- 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: [protobuf] Circular package import problem
You probably need to break up your proto files to eliminate the circular dependency.. (i.e. have multiple .proto files for a package, and only import necessary .proto files). On Mon, Feb 7, 2011 at 5:42 PM, Ken wrote: > Hi, > > I have two proto files: A.proto and B.proto. If I import package B in > A and import A in B, I got StackOverFlow exception during compiling. > Does anyone know any sulotion for it? > > Thanks, > > Ken > > -- > 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. > > -- 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: [protobuf] header update in building protobuf 2.4.0a on cygwin
Re-adding the list so that someone can consider these problems. On Mon, Feb 7, 2011 at 5:10 AM, Jim Olson wrote: > I think it was gcc/g++ 3.3, yes it's a couple years old. > > Other problems I discovered : > protoc has to be installed parallel to the java/src dir > otherwise the maven pom.xml can't find it. > I saw postings about the problems this caused but no solutions. > Perhaps you can put this in the README or INSTALL. > > And cygwin expects ; rather than : as the CLASSPATH > path separator which I think caused problems in the generated > 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: > >> 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 I had to make to get the >>> protobuf package to >>> build on cygwin. I had to make >>> >>> const': >>> ./google/protobuf/descriptor.h:1152: error: >>> >>> `google::protobuf::internal::Mutex*google::protobuf::DescriptorPool::mutex_' >>> is private >>> >>> >>> this member field public. It all built ok after doing this. (I also >>> had to move the dir to C: >>> as it had a link error due to being under C:/Documents and Settings.) >>> >>> Here is the error message excerpt I got: >>> >>> >>> libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -Wall -Wwrite-strings - >>> Woverloaded-virtual -Wno-sign-compare -O2 -g -DND >>> EBUG -MT structurally_valid.lo -MD -MP -MF .deps/ >>> structurally_valid.Tpo -c google/protobuf/stubs/structurally_valid.cc >>> -DDLL_EXPORT -DPIC -o .libs/structurally_valid.o >>> libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -Wall -Wwrite-strings - >>> Woverloaded-virtual -Wno-sign-compare -O2 -g -DND >>> EBUG -MT structurally_valid.lo -MD -MP -MF .deps/ >>> structurally_valid.Tpo -c google/protobuf/stubs/structurally_valid.cc >>> - >>> o structurally_valid.o >/dev/null 2>&1 >>> mv -f .deps/structurally_valid.Tpo .deps/structurally_valid.Plo >>> /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. >>> -I.. -Wall -Wwrite-strings -Woverloaded-virtu >>> al -Wno-sign-compare -O2 -g -DNDEBUG -MT descriptor.lo -MD -MP - >>> MF .deps/descriptor.Tpo -c -o descriptor.lo `test -f 'go >>> ogle/protobuf/descriptor.cc' || echo './'`google/protobuf/ >>> descriptor.cc >>> libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -Wall -Wwrite-strings - >>> Woverloaded-virtual -Wno-sign-compare -O2 -g -DND >>> EBUG -MT descriptor.lo -MD -MP -MF .deps/descriptor.Tpo -c google/ >>> protobuf/descriptor.cc -DDLL_EXPORT -DPIC -o .libs/de >>> scriptor.o >>> google/protobuf/descriptor.cc: In member function `virtual const >>> google::protobuf::FieldDescriptor* google::protobuf::De >>> >>> scriptorBuilder::OptionInterpreter::AggregateOptionFinder::FindExtension(google::protobuf::Message*, >>> const std::string&) >>> const': >>> ./google/protobuf/descriptor.h:1152: error: >>> >>> `google::protobuf::internal::Mutex*google::protobuf::DescriptorPool::mutex_' >>> is private >>> google/protobuf/descriptor.cc:4341: error: within this context >>> ./google/protobuf/descriptor.h:1152: error: >>> >>> `google::protobuf::internal::Mutex*google::protobuf::DescriptorPool::mutex_' >>> is private >>> google/protobuf/descriptor.cc:4342: error: within this context >>> make[2]: *** [descriptor.lo] Error 1 >>> make[2]: Leaving directory `/cygdrive/c/Documents and Settings/Jim/My >>> Documents/java/protobuf-2.4.0a/src' >>> make[1]: *** [all-recursive] Error 1 >>> make[1]: Leaving directory `/cygdrive/c/Documents and Settings/Jim/My >>> Documents/java/protobuf-2.4.0a' >>> make: *** [all] Error 2 >>> >>> -- >>> 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. >>> >>> >> > -- 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.
[protobuf] Re: Issue 250 in protobuf: [PATCH] Maven-plugin does not work with M2Eclipse
Comment #3 on issue 250 by g...@google.com: [PATCH] Maven-plugin does not work with M2Eclipse http://code.google.com/p/protobuf/issues/detail?id=250 Does the alternate plugin discussed in Issue 81 work with M2Eclipse? -- 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.
[protobuf] Re: Issue 250 in protobuf: [PATCH] Maven-plugin does not work with M2Eclipse
Updates: Blockedon: 81 Comment #2 on issue 250 by g...@google.com: [PATCH] Maven-plugin does not work with M2Eclipse http://code.google.com/p/protobuf/issues/detail?id=250 (No comment was entered for this change.) -- 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.
[protobuf] Re: Issue 81 in protobuf: Maven Protoc Plugin Code Review
Issue 81: Maven Protoc Plugin Code Review http://code.google.com/p/protobuf/issues/detail?id=81 This issue is now blocking issue 250. See http://code.google.com/p/protobuf/issues/detail?id=250 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- 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.
[protobuf] Circular package import problem
Hi, I have two proto files: A.proto and B.proto. If I import package B in A and import A in B, I got StackOverFlow exception during compiling. Does anyone know any sulotion for it? Thanks, Ken -- 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.
