Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

For Enums it is not possible - It's possible to import proto2 message types and use them in your proto3 messages, and vice versa. However, proto2 enums cannot be used in proto3 syntax. https://developers.google.com/protocol-buffers/docs

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Надеюсь,что вы не будете против моего вступления в вашу группу.Тема очень интересна. четверг, 11 декабря 2014 г., 7:51:01 UTC+3 пользователь Feng Xiao написал: > > Hi all, > > I just published protobuf v3.0.0-alpha-1 on our github site: > https://github.com/google/protobuf/releases/tag/v3.0.0-alp

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Wed, Oct 21, 2015 at 1:39 PM, wrote: > Is there a plan to also arena allocate string fields? > In the future we will introduce different ctypes for string fields and if you specify ctype=STRING_PIECE on a string field it will be stored as a StringPiece and can then be arena-allocated. There is

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Is there a plan to also arena allocate string fields? -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To post to this

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

If it possible to compile into DLL? I have not find the directory about "vsproject" which is exists in v2.0. Thanks 在 2014年12月11日星期四 UTC+8下午12:51:01，Feng Xiao写道： > > Hi all, > > I just published protobuf v3.0.0-alpha-1 on our github site: > https://github.com/google/protobuf/releases/tag/v3.0.0-a

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Hi Feng, I have a question: looks like there is no copy constructor that takes arena pointer. I got compilation error on this: feature_package::MyFeatureMessage* arena_message = Arena::CreateMessage(arena, m); I need to rewrite this in 2 steps: feature_package::MyFeatureMessage* aren

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Yes, just to expand on this - the descriptor protos aren't directly accessible, but the information contained within them is - via the public types in the Google.Protobuf.Reflection namespace. We're able to do this because we've looked (very carefully!) at how descriptor.proto works in terms of

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Will the C# implementation support proto2 messages? What is the capability story? I assume the wire format is compatible if no proto3 exclusive features are used? On Tuesday, August 4, 2015 at 5:43:36 AM UTC-7, Jon Skeet wrote: > That looks like you're expecting a protobuf.net-style approach - t

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Will the C# implementation support proto2 message as well? What is the compatibility story between proto2 and proto 3? I assume the wire format is compatible as long as no proto 3 exclusive features are used. On Tuesday, August 4, 2015 at 5:43:36 AM UTC-7, Jon Skeet wrote: > That looks like you'

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Fri, Oct 9, 2015 at 10:51 AM, Walter Schulze wrote: > In other words C# and those new languages won't be able to serialize the > descriptor? > descriptor.proto is an exception. It's allowed to be imported by proto3 files to support custom options. I.e., the following is explicitly allowed: syn

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

In other words C# and those new languages won't be able to serialize the descriptor? On 9 October 2015 at 19:44, 'Feng Xiao' via Protocol Buffers < protobuf@googlegroups.com> wrote: > The decision is not to support proto2 in C# (and probably also for all > other languages that are new in v3.0.0+)

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

The decision is not to support proto2 in C# (and probably also for all other languages that are new in v3.0.0+). On Fri, Oct 9, 2015 at 10:42 AM, Teddy Zhang wrote: > Will the C# implementation support proto2 message as well? > What is the compatibility story between proto2 and proto 3? I assume

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

That looks like you're expecting a protobuf.net-style approach - to which the answer is "no" and will continue to be "no". The C# support will continue to be based on generated code, but there's a new code generator and runtime now in the master branch. The main changes from the previous code a

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Does this version support object type in C# ? ex: [ProtoMember(1)] public object A {get;set;} thank. Vào 11:51:01 UTC+7 Thứ Năm, ngày 11 tháng 12 năm 2014, Feng Xiao đã viết: > > Hi all, > > I just published protobuf v3.0.0-alpha-1 on our github site: > https://github.com/google/protobuf/releas

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Hi, I'm really looking forward to using proto3's maps and JSON format! However, I'm curious about the decision to remove extensions. Can you give more context about the change? Extensions were nice in that the owner of the container proto didn't have to worry about additional contents, both in

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Fri, Jun 12, 2015 at 12:40 PM, Darin Gordon wrote: > Hi Feng > > What would you say is a reasonable ETA for the protobuf 3 full release? > Are you going through a series of RC's first? > We will have a series of alpha releases followed by a series of betas. The 3 full release may be in Q4 this

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Hi Feng What would you say is a reasonable ETA for the protobuf 3 full release? Are you going through a series of RC's first? On Wednesday, December 10, 2014 at 11:51:01 PM UTC-5, Feng Xiao wrote: > > Hi all, > > I just published protobuf v3.0.0-alpha-1 on our github site: > https://github.co

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Tue, May 12, 2015 at 5:58 PM, Mikhail Nikonov < michael.n.niko...@gmail.com> wrote: > First of all, thanks for the great work; I've been using protobufs for a > while, and it's good to see them evolving. > > One question - if map field is internally emulated by repeated field type, > is it pack

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

First of all, thanks for the great work; I've been using protobufs for a while, and it's good to see them evolving. One question - if map field is internally emulated by repeated field type, is it packed (e.g. [packed=true]) by default, and is there a way to pack it? As a related question, was

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Thanks for your great work. I'm considering migrating to version 3. Is existing proto2 data (i.e. serialized messages) transparently loadable in a proto3-aware application ? On Wednesday, December 10, 2014 at 11:51:01 PM UTC-5, Feng Xiao wrote: > > Hi all, > > I just published protobuf v3.0.0-al

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Thu, Apr 30, 2015 at 12:52 PM, Nikolay Mladenov < nikolay.mlade...@gmail.com> wrote: > I understand it was an intentional design decision, I just fail to > understand the reasoning for it. > I see this statement. > > >>"In proto3, this is an intentional design decision: has_...() methods > go a

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

I understand it was an intentional design decision, I just fail to understand the reasoning for it. I see this statement. >>"In proto3, this is an intentional design decision: has_...() methods go away except for message fields. For oneofs, the idiomatic API pattern is to use get_oneof_case() to c

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Nikolay, the has_foo being private is actually intentional, see this closed issue . Alfred On Wednesday, April 29, 2015 at 6:36:59 PM UTC-4, Nikolay Mladenov wrote: > > I am also evaluating proto2 vs proto3 and even though it seems proto3 > should

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Wed, Apr 29, 2015 at 6:21 AM, Nikolay Mladenov < nikolay.mlade...@gmail.com> wrote: > I am also evaluating proto2 vs proto3 and even though it seems proto3 > should be the way to go I really miss the has_** functionality in proto3. > > It seems the following proto pattern may be a workaround: >

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

I am also evaluating proto2 vs proto3 and even though it seems proto3 should be the way to go I really miss the has_** functionality in proto3. It seems the following proto pattern may be a workaround: message M{ oneof optional_value{ int32 value = 1; } } It does generate value(), se

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

The recommended way to solve this problem is to use google.protobuf.FieldMask. The client should just send a request with 1 or 2 fields plus the FieldMask, and server will perform partial update on it. protobuf will provide better support on FieldMask, which the server code can utilize to perfo

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

I just ran into this while trying to write a gRPC service that can handle forward and back compatibility. So say that a new service is running with new fields in its proto3 message and it returns this to an older client. The older client is supposed to receive it, modify one or two fields and t

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Mon, Mar 30, 2015 at 11:44 AM, Kostiantyn Shchepanovskyi < schepanov...@gmail.com> wrote: > Hi, > > 3. Removal of extensions, which are instead replaced by a new standard >> type called Any. > > > Extensions are used for custom options definition in proto2. > > import "google/protobuf/descripto

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Hi, 3. Removal of extensions, which are instead replaced by a new standard type > called Any. Extensions are used for custom options definition in proto2. import "google/protobuf/descriptor.proto"; extend google.protobuf.MessageOptions { optional string my_option = 51234; } message MyMessa

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

That's great news, thanks!!! Looking forward to proto3! Kevin On Tue, Mar 10, 2015 at 3:24 PM, Feng Xiao wrote: > > > On Thu, Feb 26, 2015 at 11:55 PM, Kevin Baker wrote: > >> Hi, >> >> Thanks for all your work with protobuf. I am excited about the changes >> with proto3 that will reduce error

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Thu, Feb 26, 2015 at 11:55 PM, Kevin Baker wrote: > Hi, > > Thanks for all your work with protobuf. I am excited about the changes > with proto3 that will reduce errors (no forgetting to set has_* in nanopb, > yay!) and will make mapping into new languages much simpler, helping our > interop c

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Hi, Thanks for all your work with protobuf. I am excited about the changes with proto3 that will reduce errors (no forgetting to set has_* in nanopb, yay!) and will make mapping into new languages much simpler, helping our interop case a lot. My question is: We are currently using protobuf pre

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Thanks for pointing me to "oneof". I gave it a try and I have two questions: 1) I see the has_() being generated for all the fields inside oneof. Is this kind of has_() function here to stay throughout subsequent V3 releases? 2) Since oneof does not allow a repeated field in both V2/3, is there p

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Sat, Feb 7, 2015 at 4:31 AM, Jeremy Swigart wrote: > I don't understand. If a message is a simple struct then the generated > wrapper code would populate it with the default as defined by the proto it > was compiled with wouldn't it? Are you suggesting that the implementation > on different pl

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

The union types are obsoleted by oneof: https://developers.google.com/protocol-buffers/docs/proto#oneof On Sat, Feb 7, 2015 at 4:53 AM, Alfred Kwan wrote: > To implement the has_boo() in 3.0 implies one boolean per each truly > optional field, which means additional maintenance is now required,

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

To implement the has_boo() in 3.0 implies one boolean per each truly optional field, which means additional maintenance is now required, e.g. matching naming scheme for the pool together with the optional struct, also should we group all booleans together or should they sit right next to the to

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

It seems to be an annoyance now to implement the recommended union types with the 3.0 because has_foo() is not longer supported. Instead of one bool for each possible message within the "union", what do you think about adding

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

I don't understand. If a message is a simple struct then the generated wrapper code would populate it with the default as defined by the proto it was compiled with wouldn't it? Are you suggesting that the implementation on different platforms would lack the wrapper objects generated by protobuf?

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Wed Jan 28 2015 at 12:06:21 PM Troy Lee wrote: > Feng, > > Version 3 removes presence logic. > How do we exam whether a field is exist or not? > This is no possible for singular primitive fields. For singular message fields, the has methods will still be generated. Basically with proto3 you'll

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Feng, Version 3 removes presence logic. How do we exam whether a field is exist or not? Thanks, troylee Feng Xiao於 2014年12月11日星期四 UTC+8下午12時51分01秒寫道： > > Hi all, > > I just published protobuf v3.0.0-alpha-1 on our github site: > https://github.com/google/protobuf/releases/tag/v3.0.0-alpha-1 >

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

I have declared quite a few file, message, field, etc. extensions on the descriptor. https://github.com/gogo/protobuf/blob/master/gogoproto/gogo.proto These extensions are used to modify the code that is generated. This results in a user being able to create a proto file like this https://github.c

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Tue Jan 27 2015 at 5:42:34 AM Walter Schulze wrote: > Will the extensions in the descriptor.proto also be changed to Any types? > No. That will continue to be supported. descriptor.proto is the only proto that will allow extensions in proto3. > > On Thursday, 11 December 2014 06:51:01 UTC+2,

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Will the extensions in the descriptor.proto also be changed to Any types? On Thursday, 11 December 2014 06:51:01 UTC+2, Feng Xiao wrote: > > Hi all, > > I just published protobuf v3.0.0-alpha-1 on our github site: > https://github.com/google/protobuf/releases/tag/v3.0.0-alpha-1 > > This is the fir

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Mon Jan 26 2015 at 5:38:22 PM Ryan Gaudon wrote: > As a new user it's encouraged to begin implementation with PB3.0+ opposed > to 2.6. With that being said, since I'm beginning integration now and > replacing XStream with this, where would you suggest I start? There is very > little / no docum

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

As a new user it's encouraged to begin implementation with PB3.0+ opposed to 2.6. With that being said, since I'm beginning integration now and replacing XStream with this, where would you suggest I start? There is very little / no documentation available at this time, and there hasn't been an

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Thu Jan 22 2015 at 4:53:53 PM wrote: > > As a new user, we still have need (C++ target) for default values, as well > as required fields (e.g., message headers for embedded target). > > 1) It appears that you are completely removing the default/required > capability from the proto3 language.

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

As a new user, we still have need (C++ target) for default values, as well as required fields (e.g., message headers for embedded target). 1) It appears that you are completely removing the default/required capability from the proto3 language. Is this correct ? 2) Will the proto2 language be

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

The proto3 design discussion has lasted for more than half a year and all of them happened as an internal process. We have a lot of design docs, email exchanges and weekly design meetings, but they are not available for public consumption. Currently we are preparing public documentations for proto3

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Specially makes difficult for adoption in financial applications, the has_field was one of the key reasons to migrate over to protofuf. Financial applications need differentiation in-between 0 value set and not set. Eg: Limit order with 0 price is valid but with no price set is invalid. Likewis

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Which forum was this discussed (dropping of default) ? May be reading it would give some insights into the details. Regards, Sumit Kumar > On 13 Jan 2015, at 2:40 pm, Arjun Satish wrote: > > Would it be possible to re-introduce this feature in a subsequent release? It > seems like you are sti

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Interesting changes in proto3. I checked out alpha-1, and tried building it in VS2013. Gtest is missing from this release, I had to copy it from 2.6.0, but managed to build it in the end. Finally each project has its own build folder. The following 3 tests fail: [ FAILED ] BootstrapTest.Genera

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

I suppose what I'm really wondering is: a) How does it simplify the language implementations exactly? b) Why was that not the case for *non*-primitives, which still have presence logic? On Friday, January 16, 2015 at 6:39:56 PM UTC-5, Feng Xiao wrote: > > The reason for dropping field presence i

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Thu Jan 15 2015 at 1:10:10 PM Arjun Satish wrote: > Feng, > > Would it not be better to throw errors/exceptions when you try to > serialize to JSON (from languages like C++ or Java) or when code is > generated for these particular languages, rather than completely remove the > feature across t

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

The reason for dropping field presence is more of the same with dropping default values. Basically we want to simplify protobuf and make it easier to implement efficiently in more languages. We are preparing the proto3 documentation and will share more information about the trade-offs we have made.

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Can I ask for more details about why presence logic was removed (e.g. hasFoo() ) for primitives? This has been a very useful feature for us. 1. Removal of field presence logic for primitive value fields, removal > of required fields, and removal of default values. This makes > pro

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Feng, Would it not be better to throw errors/exceptions when you try to serialize to JSON (from languages like C++ or Java) or when code is generated for these particular languages, rather than completely remove the feature across the board? On Thu, Jan 15, 2015 at 12:16 PM, 'Feng Xiao' via Pro

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Thu Jan 15 2015 at 7:01:33 AM Alex Antonov wrote: > I fully second that opinion. We rely a lot on being able to set explicit > defaults that are not language defaults (Java 0, "", false, etc). It > puzzles me to even think as to why someone might want to take that feature > away!!! > The dec

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Tue Jan 13 2015 at 3:17:26 PM Arjun Satish wrote: > Since this feature is never going to be exposed, what advice do you have > for people who are using this feature and want to migrate to v3? Also, what > can we do as users to skip encoding certain fields with the new library? > We are aware o

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

I fully second that opinion. We rely a lot on being able to set explicit defaults that are not language defaults (Java 0, "", false, etc). It puzzles me to even think as to why someone might want to take that feature away!!! On Wednesday, January 14, 2015 at 6:50:37 AM UTC-6, Jeremy Swigart w

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

That sounds like a poor design decision, and one easily readded without breaking anything. If a field doesn't have an explicit default, you use 0 or whatever, thereby not breaking anyone not using them, but if an explicit default is provided that is used instead. I am using that feature as well.

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Since this feature is never going to be exposed, what advice do you have for people who are using this feature and want to migrate to v3? Also, what can we do as users to skip encoding certain fields with the new library? Thanks, On Tue, Jan 13, 2015 at 3:10 PM, Feng Xiao wrote: > > > On Tue, J

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Tue, Jan 13, 2015 at 3:05 PM, Arjun Satish wrote: > Feng, > > What do you mean when you say "In C++/Java/Python where we support both > proto2 and proto3, default values will continue to exist"? > What I meant is that you can still find its traces in the implementation but the feature itself i

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Feng, What do you mean when you say "In C++/Java/Python where we support both proto2 and proto3, default values will continue to exist"? When I run protoc (v3) with the syntax="proto3" tag, it shows an error "Explicit default values are not allowed in proto3." and exits (no code is generated). Thi

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Mon, Jan 12, 2015 at 10:40 PM, Arjun Satish wrote: > Would it be possible to re-introduce this feature in a subsequent release? > It seems like you are still using it under-the-hood. > In C++/Java/Python where we support both proto2 and proto3, default values will continue to exist. In new lan

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Would it be possible to re-introduce this feature in a subsequent release? It seems like you are still using it under-the-hood. And because of the benefits I mentioned above, I strongly feel that it will only help the community. Best, On Wed, Jan 7, 2015 at 8:01 PM, Feng Xiao wrote: > +liujisi,

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

+liujisi, who should have a better idea of why default value is dropped from proto3 and what alternatives users can rely on. Internally the design of proto3 has been discussed among a group of people for quite a long time, but most of them haven't subscribed this forum though... On Wed, Jan 7, 201

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Did anyone get a chance to look at this request? On Wednesday, December 17, 2014 3:54:12 PM UTC-8, Arjun Satish wrote: > > Hey guys, > > Thanks for all the hard work! > > I have a question regarding the decision to drop support for default > values. Fields which are set to their default values

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Hey guys, Thanks for all the hard work! I have a question regarding the decision to drop support for default values. Fields which are set to their default values are not serialized. I noticed that in the new code (3.0.0-alpha-1 for Java), this condition still holds true. But the default value

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Oh, bummer. I was hoping for a more compact map packing. Currently I'm using the following to do this: repeated uint32 properties = 1; // key/value index pairs repeated string keys = 2; // unique keys repeated string values = 3; // unique values On Thursday, December 11, 2014 2:24:09 PM UTC-5, F

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

On Thu, Dec 11, 2014 at 9:14 AM, Vladimir Agafonkin wrote: > > Really awesome! > > One question about maps — how are they encoded in terms of packed size? > How does it compare to just using a repeated message with key/value pairs? > Map fields are encoded as a repeated message field. The followin

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

Really awesome! One question about maps — how are they encoded in terms of packed size? How does it compare to just using a repeated message with key/value pairs? On Wednesday, December 10, 2014 11:51:01 PM UTC-5, Feng Xiao wrote: > > Hi all, > > I just published protobuf v3.0.0-alpha-1 on our g