Re: [protobuf] Why does protobuf-net append to a byte[] Property/field on deserialize?

2011-02-01 Thread Marc Gravell
I'll see if I can add something when I get chance, but note that you could also work around this by using serialization callbacks to detect when deserialization is starting, and wipe the default BLOB. Also, the elusively unreleased v2 also optionally supports ctor-skipping (like

Re: [protobuf] Recursion support in Protobuf-net

2011-02-01 Thread Marc Gravell
Yes, that is already on my list of things I really, really want it to do. It will inevitably be in v2 at some point, but to repeat your point: this will be 100% implementation specific and not generically portable between platforms, so it will have to be by explicit opt in. Marc On 1 February

Re: [protobuf] Serializing Dictionarystring,object

2011-02-01 Thread Marc Gravell
Both, really. And of course by the time you are embedding **type** metadata into the file you have ceased to be portable (or contract-based). This is potentially something that could be added as a non-portable feature of a single implementation, but *in most cases* there are ways to do it

Re: [protobuf] Support for generic surrogates, eg. QueueT

2011-02-01 Thread Marc Gravell
Nice - I'm glad that was a v2 patch, though ;p Before I look at that at any length, though, can you confirm that you can freely release this patch under the existing license terms? (just my CYA) Marc On 1 February 2011 03:03, NYCBrit tristra...@googlemail.com wrote: I've made a small

[protobuf] Repeated Fields Encoding

2011-02-01 Thread Timothy Parez
Hello, Considering the following proto file: message FileDescriptor { required string Filename = 1; optional int64 Size = 2 [default = 0]; } message FileList { repeated FileDescriptor Files = 1; } If you create something like this: (and I'm duplicating the data because

Re: [protobuf] Repeated Fields Encoding

2011-02-01 Thread Marc Gravell
I think this also came to me directly and I answered earlier, but this is the expected layout of repeated data, where each item in a list is mapped separately in the data stream. Marc On 1 Feb 2011, at 11:01, Timothy Parez timothypa...@gmail.com wrote: Hello, Considering the following

[protobuf] New protobuf feature proposal: Generated classes for streaming / visitors

2011-02-01 Thread Kenton Varda
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

Re: [protobuf] Repeated Fields Encoding

2011-02-01 Thread Kenton Varda
The encoding is documented in detail here: http://code.google.com/apis/protocolbuffers/docs/encoding.html http://code.google.com/apis/protocolbuffers/docs/encoding.htmlThe short answer is, yes, repeated fields are literally encoded as repeated individual values, unless you use packed encoding.

[protobuf] v2.4 question

2011-02-01 Thread David Dabbs
Hello. From what I gather catching up on list messages, 2.4 is final, but not officially released, perhaps because some documentation is in the works. I ask because I would like to incorporate 2.4 in my product's upcoming build cycle, but only if there is reasonable certainty that the bits

[protobuf] Services not compiling

2011-02-01 Thread jdoliner
Hi, I'm new to protocol buffers so apologies if this is something stupid. (I searched the forum and didn't find anything). I'm having a problem getting services to compile. I have the following population.proto file: package population; message addrinfo { required fixed32 ip = 1;

Re: [protobuf] Services not compiling

2011-02-01 Thread Kenton Varda
The *_generic_services options now default to false. You must explicitly set them to true, e.g.: option cc_generic_services = true; option java_generic_services = true; option py_generic_services = true; We decided to make these off-by-default because we want to encourage RPC

[protobuf] Re: New protobuf feature proposal: Generated classes for streaming / visitors

2011-02-01 Thread Jason Hsueh
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

Re: [protobuf] Protocol Buffers Python extension in C

2011-02-01 Thread Atamurad Hezretkuliyev
I've implemented code generator so others can test / use our C implementation in Python. Another new thing is Lazy decoding support. Message are decoded on the fly as attributes are accessed for the first time. More info: http://blog.connex.io/introducing-cypb-improving-the-performance-of You

RE: [protobuf] Support for generic surrogates, eg. QueueT

2011-02-01 Thread Richard Geary
Yes, I've no problem with releasing it under the existing (Apache 2) license terms. From: Marc Gravell [mailto:marc.grav...@gmail.com] Sent: 01 February 2011 03:18 To: NYCBrit Cc: Protocol Buffers Subject: Re: [protobuf] Support for generic surrogates, eg. QueueT Nice - I'm glad that was

[protobuf] Re: New protobuf feature proposal: Generated classes for streaming / visitors

2011-02-01 Thread Kenton Varda
On Tue, Feb 1, 2011 at 3:17 PM, Jason Hsueh jas...@google.com 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

Re: [protobuf] Re: inheritance.. well sort of... and FieldDescriptors

2011-02-01 Thread Kenton Varda
You can't use the same field descriptors for the four classes. But, note that one thing you *can* do is define a base type that just contains the shared fields, and then parse any of the other types as this type in order to access the common fields. Since the field numbers match, they are