[protobuf] Managing extension ranges
Hi, I'm working on a project which uses extensions quite a lot, but as the project gets bigger I find it quite difficult to manage extension numbers in order to prevent collisions. This is true for extension of protobuf's MessageOptions, FieldOptions (i.e. internal custom options within range 5-9), as well as for any other extension of any custom message. I would like to generate a synthetic report showing which extension numbers are used within a set of proto files. This is easy to do, but I wonder whether someone already did something like that. If not, which other means do you use to manage your extensions numbers? Thanks, Louis-Marie -- 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] Python installation does not build plugin_pb2
Hi all, It looks like python installation of protocol buffers does not generate the google.protobuf.compiler.plugin_pb2 python file, while google.protobuf.descriptor_pb2 is explicitly generated by protobuf/python/setup.py generate_proto(../src/google/protobuf/descriptor.proto) Shouldn't the plugin.proto file be compiled and installed the same way? Maybe I am missing something there, be I feel very uncomfortable recompiling it when I need to write a plugin. Thanks, Louis-Marie -- 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, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Detecting end of CodedInputStream
Hi, I'm using a CodedInputStream, based on a FileInputStream in C++ to read a sequence of size delimited messages (as discussed in recent posts, I'm building a new CodedInputStream object for each new message, in order to allow parsing large number of events without reaching the total bytes limit). Before reading the size of the message and then its body, I'm calling the ExpectAtEnd() method to check whether we reached end of stream. However, it always returns false (which causes my program to report a warning about junk at end of stream...) Looking at source code, my understanding is that this method will never return true, unless we have an explicit limit pushed on the CodedInputStream. My question is then: how can I safely detect end of file? I guess I could do something like calling Next() on the underlying FileInputStream until it returns false (end of file) or a non empty buffer (and then call BackUp() to re-queue this buffer before creating the CodedInputStream), but it seems a bit overkill (and probably not the best thing from a performance point of view...) Thanks for your advices, Louis-Marie -- 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, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Inspect contents of a DescriptorPool object
Hi all, I'm writing a C++ library function which reads protocol buffer objects from an input stream and returns an abstract Message object to caller. When descriptors are not known at compile-time, I use a DescriptorPool::BuildFile() call to load them dynamically. I inspect each loaded file to find messages which are valid top-level objects to be parsed from my input stream (they are tagged with a custom option). However, library client may want to use objects he knows at compile- time (typically dynamic_cast'ing them, rather than getting DynamicMessage instances), so I would like to inspect the generated_pool itself to index valid descriptors it might contain. This way, I could build objects based on descriptions from generated_pool. I can't figure out how to browse a DesciptorPool (I would need a way to iterate over the whole list of FileDescriptor objects). Looking at sources, it seems it would not be so difficult to implement that, but I probably miss something... I wrote a small protoc plugin which inserts self-registration code in each generated *.pb.cc file. This way, I can use the resulting file list to get the descriptor using DescriptorPool::generated_pool()- FindFileByName() but it is totally redundant with generated pool's built-in registration system. What do you think would be the good solution to do that? Thanks, Louis-Marie -- 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, visit this group at http://groups.google.com/group/protobuf?hl=en.
