RE: Storing complex graphs of objects?
Hi Kenton - Thanks for your help. Obviously defining message types in proto files is crucial for being able to exchange messages between different languages. However, as a substitute for Java serialisation having to specify message types in separate files from the source files seems less than ideal. What I was thinking of was more along the lines of adding methods to each object to be serialised via PB that look like the methods on the classes the PB compiler generates --- writeTo() and parseFrom(). These would work analogously to the way that writeObject() and readObject() for normal serialisation, but by trading away the unrestricted polymorhism that this type of application doesn't need it allow it to write ints rather than class names to distinguish types and would hopefully also gain from the extra efficiencies of CodedInputStream and CodedOutputStream. Best regards, Paul _ Looking to change your car this year? Find car news, reviews and more http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641_t=762955845_r=tig_OCT07_m=EXT --~--~-~--~~~---~--~~ 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: Crash while initializing StaticDescriptorInitializer
On Thu, Mar 26, 2009 at 6:57 PM, Kenton Varda ken...@google.com wrote: On Thu, Mar 26, 2009 at 9:28 AM, Jesper jesper.eskil...@gmail.com wrote: I think so, but I'll double-check. (Wouldn't that have showed up when libprotobuf.lib was linked into the exe?) Unfortunately, probably not. Strange crashes at runtime are the usual symptom. :( It turned out to be caused by a mismatch in using _SECURE_SCL, i.e. checked iterators. Just to add to the Debug/Release problems, Microsoft has added extra defines which must not be mixed -- _SECURE_SCL affects the binary layout of STL containers, so it has to be defined the same way everywhere, and unfortunately the code I'm working on has a non-default setting for _SECURE_SCL. Thanks anyway for all the help. (BTW: I created a set of CMake (http://cmake.org) build files for Protobufs, in case you're interested in not maintaining parallell Makefiles/project files for Linux/Windows.) -- /Jesper --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Streaming different types of messages
If I understand correctly there is no good way to use proto buffers to stream different types of messages, right? For example if my stream has a mix of several messages of type m1 and m2, I will have to device a scheme outside of proto buffers to separate it into 2 streams and then pass it through parsers for each. In other words is there a way to do event based parsing using proto buffers, or even a way to say don't parse a repetitive field unless needed. --~--~-~--~~~---~--~~ 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: Streaming different types of messages
On Mar 27, 1:32 pm, achin...@gmail.com wrote: If I understand correctly there is no good way to use proto buffers to stream different types of messages, right? For example if my stream has a mix of several messages of type m1 and m2, I will have to device a scheme outside of proto buffers to separate it into 2 streams and then pass it through parsers for each. In other words is there a way to do event based parsing using proto buffers, or even a way to say don't parse a repetitive field unless needed. No, you don't have to do it into separate streams. Instead, stream a sequence of messages each of which has either an m1, or an m2, or an m3 etc. This basically ends up being (tag) (message) (tag) (message), where the tag is effectively identifying the type of message. All you need to do is create the wrapper message, and the rest should work fine. Jon --~--~-~--~~~---~--~~ 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: Streaming different types of messages
Kenton, I don't suppose there'd ever be a way to mark a set of fields as mutually exclusive? -dave On Mar 27, 8:42 am, Jon Skeet sk...@pobox.com sk...@pobox.com wrote: On Mar 27, 1:32 pm, achin...@gmail.com wrote: If I understand correctly there is no good way to use proto buffers to stream different types of messages, right? For example if my stream has a mix of several messages of type m1 and m2, I will have to device a scheme outside of proto buffers to separate it into 2 streams and then pass it through parsers for each. In other words is there a way to do event based parsing using proto buffers, or even a way to say don't parse a repetitive field unless needed. No, you don't have to do it into separate streams. Instead, stream a sequence of messages each of which has either an m1, or an m2, or an m3 etc. This basically ends up being (tag) (message) (tag) (message), where the tag is effectively identifying the type of message. All you need to do is create the wrapper message, and the rest should work fine. Jon --~--~-~--~~~---~--~~ 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: Streaming different types of messages
achin...@gmail.com writes: Thanks. Also how do I know the type of the message? One way would be to check all optional fields (each represent a different type of message) of the wrapper message and then pick the one which is not null. Is that the only way? You can add a (required) field to indicate the intended contents of the message, as described at http://code.google.com/apis/protocolbuffers/docs/techniques.html#union Note that Protocol Buffers will not enforce the business rule that the message's declared type and actual content must match, but it is straightforward to create a wrapper that will do that. Michael Poole --~--~-~--~~~---~--~~ 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: Crash while initializing StaticDescriptorInitializer
On Fri, Mar 27, 2009 at 3:33 AM, Jesper Eskilson jes...@eskilson.se wrote: (BTW: I created a set of CMake (http://cmake.org) build files for Protobufs, in case you're interested in not maintaining parallell Makefiles/project files for Linux/Windows.) We considered using cmake originally, but decided it was more important to avoid making users download extra tools before they could compile protocol buffers. So I continue to toil away, maintaining MSVC project files, as silly as they are... --~--~-~--~~~---~--~~ 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: Storing complex graphs of objects?
You could treat the protobuf classes as private implemnetation helpers. Your public interface would have methods like you describe, and internally they'd just copy the object's state into a protocol buffer and then serialize it. On Fri, Mar 27, 2009 at 2:32 AM, Paul Runyan paul_run...@hotmail.comwrote: Hi Kenton - Thanks for your help. Obviously defining message types in proto files is crucial for being able to exchange messages between different languages. However, as a substitute for Java serialisation having to specify message types in separate files from the source files seems less than ideal. What I was thinking of was more along the lines of adding methods to each object to be serialised via PB that look like the methods on the classes the PB compiler generates --- writeTo() and parseFrom(). These would work analogously to the way that writeObject() and readObject() for normal serialisation, but by trading away the unrestricted polymorhism that this type of application doesn't need it allow it to write ints rather than class names to distinguish types and would hopefully also gain from the extra efficiencies of CodedInputStream and CodedOutputStream. Best regards, Paul -- Find car news, reviews and more Looking to change your car this year?http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641_t=762955845_r=tig_OCT07_m=EXT --~--~-~--~~~---~--~~ 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: Crash while initializing StaticDescriptorInitializer
On Fri, Mar 27, 2009 at 8:08 PM, Kenton Varda ken...@google.com wrote: On Fri, Mar 27, 2009 at 3:33 AM, Jesper Eskilson jes...@eskilson.se wrote: (BTW: I created a set of CMake (http://cmake.org) build files for Protobufs, in case you're interested in not maintaining parallell Makefiles/project files for Linux/Windows.) We considered using cmake originally, but decided it was more important to avoid making users download extra tools before they could compile protocol buffers. So I continue to toil away, maintaining MSVC project files, as silly as they are... That is one major hurdle for getting people to like CMake; you need an extra tool before you get your buildfiles. If CMake just could create relocatable project files, things would look much brighter. -- /Jesper --~--~-~--~~~---~--~~ 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: Memory leaks on VS2008/C++
On 3/27/2009 3:19 PM, Oleg Smolsky wrote: Weird... DescriptorPool is destroyed, and so it DescriptorPool::Tables which frees its 52 outstanding allocations... OK, I made a silly mistake - I was dumping allocations before static destructors were executed. Oops. I've just verified the test and the code - the merged/updated patch that I posted at the beginning of the thread does address all leaks. So, the next question is - would it ever make its way into your SVN? If so, do you see a need for a switch of some kind? Kind regards, Oleg. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
