Re: [protobuf] Re: protobuf js custom options

[Arpit Baldeva]

Sorry, I did not investigate it further (I don't currently have a use case
of it - I was just testing the support).

On Wed, Jun 6, 2018 at 10:26 AM,  wrote:

> Hi Arpit,
>
> Did you have any luck?
>
>
> On Friday, October 6, 2017 at 3:24:09 PM UTC-7, Arpit Baldeva wrote:
>>
>> Hi,
>>
>> Are custom options supported with protobuf JS? I have my proto files that
>> work fine with C++/C# so I don't think it is a syntax issue.
>>
>> However, when I try to run the grpc sample (I am not sure it is a grpc
>> issue though), I get an error similar to https://github.com/dcodeIO/
>> protobuf.js/issues/383
>>
>> Parse error at line 5: illegal option name: (toplevel_3.options).,
>>
>>
>>  Thanks.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Protocol Buffers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/protobuf/TP1rViMydKM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> Visit this group at https://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] protoc input dependency checking (--dependency_out)

[Arpit Baldeva]

Hi,

I tried using --dependency_out option and ran into a few issues.

   1. It does not work with multiple files input. Are there any plans to 
   add that support? 
   2. I noticed that the dependency file includes the whole dependency 
   chain from other proto files. I am not sure if it is necessary. So if there 
   is foo.proto that includes bar.proto and someone makes a change in 
   bar.proto, I don't think generating code for foo.proto is a necessity. Is 
   there something I am missing here?
   3. The option actually did not work for me. But I did not dig into it 
   too much because I wanted to figure out 1&2 first.


Thanks.

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] C++ - Protobuf descriptor static memory leaks

[Arpit Baldeva]

Hi,

Currently, protobuf generated code makes allocations in the static 
descriptor objects. For example, valgrind reports

 
   Memcheck:Leak
   fun:malloc
   fun:_ZN20PassthroughAllocator5AllocEmPKcj
   fun:_Znwm
  
 
fun:_ZN6google8protobuf14DescriptorPoolC1EPNS0_18DescriptorDatabaseEPNS1_14ErrorCollectorE
   fun:_ZN6google8protobuf12_GLOBAL__N_1L17InitGeneratedPoolEv
   fun:_ZN6google8protobuf8internal16FunctionClosure03RunEv
   fun:_ZN6google8protobuf18GoogleOnceInitImplEPlPNS0_7ClosureE
   fun:_ZN6google8protobuf14GoogleOnceInitEPlPFvvE
   fun:_ZN6google8protobuf12_GLOBAL__N_121InitGeneratedPoolOnceEv
   fun:_ZN6google8protobuf14DescriptorPool24InternalAddGeneratedFileEPKvi
  
 
fun:_ZN5Blaze51protobuf_blaze_2fprotobuf_2fblazeextensions_2eproto12_GLOBAL__N_118AddDescriptorsImplEv
   fun:_ZN6google8protobuf8internal16FunctionClosure03RunEv
   fun:_ZN6google8protobuf18GoogleOnceInitImplEPlPNS0_7ClosureE
   fun:_ZN6google8protobuf14GoogleOnceInitEPlPFvvE
  
 
fun:_ZN5Blaze51protobuf_blaze_2fprotobuf_2fblazeextensions_2eproto14AddDescriptorsEv
  
 
fun:_ZN5Blaze51protobuf_blaze_2fprotobuf_2fblazeextensions_2eproto27StaticDescriptorInitializerC1Ev
   fun:_Z41__static_initialization_and_destruction_0ii
   fun:_GLOBAL__sub_I_blazeextensions.pb.cc

Is there a convenience function that could deallocate these objects so that 
I don't have to suppress these allocations? Found this relevant issue 
- https://codereview.appspot.com/7918 - 9 years ago. 

Thanks.  

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] protobuf js custom options

[Arpit Baldeva]

Hi,

Are custom options supported with protobuf JS? I have my proto files that 
work fine with C++/C# so I don't think it is a syntax issue. 

However, when I try to run the grpc sample (I am not sure it is a grpc 
issue though), I get an error similar 
to https://github.com/dcodeIO/protobuf.js/issues/383 

Parse error at line 5: illegal option name: (toplevel_3.options).,


 Thanks. 

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] Why doesn't protobuf C++ include smart pointers to submessages?

[Arpit Baldeva]

A weak_ptr needs a shared_ptr to begin with so all the submessages would 
end up being a shared_ptr (creating an impression that they are meant for 
shared ownership). In fact, I feel that Protobuf could perhaps change the 
generated code to use unique_ptr instead of it's raw pointers to more 
clearly express the ownership semantics.

For your use case, why can't you just copy the sub message you are 
interested in? What use case would rule that out as an option?  

On Friday, July 21, 2017 at 11:11:39 AM UTC-7, Alex Shaver wrote:
>
> I agree that since the model is that the top message owns its submessages, 
> the idea of shared ownership isn't necessarily useful. But something like a 
> weak pointer doesn't change the ownership, it would just allow objects to 
> be responsive to whether the submessage exists or not. 
>
> While holding a reference to the top level message does technically 
> resolve the problem, I feel like it breaks a bit of modularity; my object 
> doesn't need to know about its sibling submessages, nor the broader 
> message. Further, there's the issue of finding my submessage for a specific 
> object. I could provide both a pointer to the larger object and to the 
> smaller one, but that just gets us back to the initial problem. So I have 
> to give it some algorithm to find which message I want. This then becomes 
> fragile to schema changes to the protobuf (the object must be updated to 
> some new path algorithm), but more importantly, still leaves the issue of 
> when the submessage is deleted ambiguous. Let's say it used to search for 
> the 3rd item in a repeated field, but the 3rd item is deleted somewhere 
> else. It doesn't know the 3rd Item is gone, because it sees what used to be 
> the 4th.
>
> It may just be that this is something protobuf can't do, and using it we 
> just have to deal with that fact or do some additional codework so that 
> every time a submessage is deleted all the things using it are notified and 
> respond appropriately (with probably some decent unit testing to feel a bit 
> more confident). But I feel like some kind of weak pointer, even if it was 
> a class included in the protobuf library and not the std::weak_ptr class, 
> would really help to resolve some of these issues in a consistent manner.
>
> On Friday, July 21, 2017 at 12:18:20 PM UTC-4, Adam Cozzette wrote:
>>
>> I think this would be a pretty difficult and invasive change to make, 
>> because the basic memory model used by C++ protobuf is that each message 
>> has sole ownership of its submessages, with no notion of shared ownership. 
>> If we did introduce a change like this, it would also force existing users 
>> to pay a runtime cost for this feature even though they don't use it. In 
>> your case I would guess that the best solution would be to avoid hanging 
>> onto a pointer to the submessage, but instead just hold a pointer or 
>> reference to the parent message. That way you can always still access the 
>> submessage or at least observe if it has been cleared, without risk of a 
>> dangling pointer.
>>
>> On Wed, Jul 19, 2017 at 11:08 AM, Alex Shaver  wrote:
>>
>>> If I have a
>>> message Foo{
>>>Bar bar = 1;
>>> }   
>>>
>>> I can get a
>>> Bar* bar = foo.mutable_bar();   
>>>
>>> I'd like to be able to get, at the very least
>>> std::weak_ptr bar = foo.mutable_bar();   
>>> if not a std::shared_ptr. 
>>>
>>> I have an issue where an object has to hold a raw pointer to a 
>>> submessage, and it is possible to delete that submessage (using the 
>>> message's API elsewhere), in a way that the object isn't aware of, and it 
>>> attempts to use that stale pointer. This is one of the principle issues 
>>> addressed with use of smart pointers, and it's unclear why protobuf cannot 
>>> provide them. I don't understand the Arena allocation enough, if it is a 
>>> problem there, but it seems like that would at least provide some way for 
>>> weak_ptr to work. Or even if protobuf had its own custom template class 
>>> that behaved like a weak pointer so that I can at least be sure I don't 
>>> have stale pointers or references floating around in my code.
>>>
>>>
>>>
>>> -- 
>>> 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+u...@googlegroups.com.
>>> To post to this group, send email to prot...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/protobuf.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more 

Re: [protobuf] Next release tentative due date(3.4.0)

[Arpit Baldeva]

Thanks.

In general, is there a release schedule? Like once a quarter, once every X 
weeks etc?



On Friday, July 21, 2017 at 2:46:34 PM UTC-7, Bo Yang wrote:
>
> https://github.com/google/protobuf/milestone/20
> ETA is end of this month.
>
> On Thu, Jul 20, 2017 at 1:26 PM Arpit Baldeva <abal...@gmail.com 
> > wrote:
>
>> Hi,
>>
>> Is there a release schedule page that I can follow for upcoming release 
>> dates? I am interested in knowing the next release due date (tentative is 
>> fine).
>>
>> Thanks.
>>
>> -- 
>> 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+u...@googlegroups.com .
>> To post to this group, send email to prot...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Next release tentative due date(3.4.0)

[Arpit Baldeva]

Hi,

Is there a release schedule page that I can follow for upcoming release 
dates? I am interested in knowing the next release due date (tentative is 
fine).

Thanks.

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Json object hash

[Arpit Baldeva]

A list as a 'value type' in not supported for map. I have not worked with 
JavaScript and protobuf but I believe in the other languages, it will be a 
code generation error.

In general, I have had the similar problems you have when you need to come 
up with a particular json format which protobuf does not support. For 
example, you can not have a list of list. The 'workaround' in this scenario 
is to use

https://github.com/google/protobuf/blob/master/src/google/protobuf/struct.proto 

The library has special support the above proto file. I mention special 
support because even if you make a verbatim copy of the above proto message 
and use it, your json format would end up being different. 

For your use case, you'd want to set the oneof in the Value protobuf to the 
list. 


On Wednesday, July 5, 2017 at 8:06:23 AM UTC-7, al...@nvent.nl wrote:
>
> Hi everyone,
>
> I'm trying to produce a specific response format and I'm struggling with 
> the protobuf syntax to generate it. Worth mentioning, I'm new to protobuf 
> and am struggling a bit with the docs, so it's likely that I missed 
> something.
>
> The format I'm trying to produce, in json:
>
> {
>   success: false
>   errors: {
> field1: ["error message 1", "error message 2"]
> field2: []
> ...fields
>   }
> }
>
> The proto syntax that I came up with looks like this:
> message ResponseSubmit {
>   bool success = 1
>   map errors = 2
> }
>
> message ErrorList {
>   repeated string error = 1
> }
>
> Then, using the generated javascript libraries:
>
> const response = new ResponseSubmit();
> const errorsMap = response.getErrorsMap();
> const valid = true;
> const errors ={ field1: [], field2: ['Dummy error message'] };
>
> response.setSuccess(valid); // this works ok
>
> forEachObjIndexed((fieldErrors, fieldName) => {
>   errorsMap.set(fieldName, fieldErrors); // this blows up 
> });
>
> Adding a field to the map via the set method crashes with a TypeError: 
> b.toArray is not a function.
>
> Can anyone lend a hand and point me to what I'm doing wrong here?
>
> Thank you!
>
> Alex
>
>

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] extending field and message options

[Arpit Baldeva]

Hi,

I have my proto file like following.

package example;

message ExFieldOptions 
{
  map meta_data = 1;
}

extend google.protobuf.FieldOptions 
{
ExFieldOptions exOptions = 4245; 
}

extend google.protobuf.MessageOptions 
{
ExFieldOptions exOptions = 4245; 
} 

When I run it through ProtoC (for C++ code generation), I run into an error

"exOptions" is already defined in "example".

Is this a bug? Or is it required that extension name need to be unique 
across options?

Thanks. 

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] package attribute

[Arpit Baldeva]

Hi,

While working with proto files, I realized that I can place the package 
attribute anywhere in the file and all the messages (even the ones above 
it) get put in the namespace generated due to the package attribute (C++).

Is that a 'feature' I can rely upon ? In other words, ProtoC does not care 
about the location of package attribute in the file?

Thanks.

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] typedef support

[Arpit Baldeva]

Hi Adam,

Thanks for the response. I agree that any change should be scrutinized and
evaluated very carefully.

I am somewhat surprised though. May be it has to do with my primary
language background being C++ where typedefs are commonplace. Defining a
new message just to embed a single value will work but is cumbersome.
Nonetheless, I'll file the issue for further feedback.

Sincerely,
Arpit

On Wed, Jan 18, 2017 at 10:59 AM, Adam Cozzette <acozze...@google.com>
wrote:

> Arpit, I should just let you know in advance that we tend to be pretty
> conservative about making a big change like this and so we would probably
> be reluctant to do it unless it has a major positive impact. I'm skeptical
> of whether this feature adds enough value, because most of the time I think
> developers already solve this issue by defining new message types and
> reusing them as submessages. Feel free to file an issue, though, if you
> think you can make a good argument for why the feature is worth it.
>
> On Tue, Jan 17, 2017 at 3:29 PM, Arpit Baldeva <abald...@gmail.com> wrote:
>
>> Should I file a GitHub issue for this? I am not sure what the right
>> protocol is.
>>
>> Thanks.
>>
>> On Wednesday, November 23, 2016 at 1:04:07 PM UTC-8, Arpit Baldeva wrote:
>>>
>>> Thanks for the info. Typedef support would be pretty much useful for
>>> regular use cases in C/C++ languages. For example, if we have 100 messages
>>> that each have a game id, it'd be nice to just typedef say a uint64 to
>>> GameId rather than using it explicitly in each place. This avoids errors
>>> like someone using int64 accidentally in one of the messages. Another
>>> example would be typedef-ing a collection like map or repeated fields which
>>> are used in multiple messages.
>>>
>>> --Arpit
>>>
>>> On Wed, Nov 23, 2016 at 11:24 AM, Adam Cozzette <acozze...@google.com>
>>> wrote:
>>>
>>>> I don't think we have any specific plans to do this, but we could
>>>> consider doing at some point if it would be useful. Do you have a
>>>> particular use case that would benefit from support for type aliasing?
>>>>
>>>> On Mon, Nov 21, 2016 at 4:13 PM, Arpit Baldeva <abald...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Are there any plans to introduce typedef support in the Proto files?
>>>>>
>>>>> Thanks
>>>>> Arpit
>>>>>
>>>>> --
>>>>> 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 group, send email to protobuf@googlegroups.com.
>>>>> Visit this group at https://groups.google.com/group/protobuf.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>> --
>> 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 group, send email to protobuf@googlegroups.com.
>> Visit this group at https://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] typedef support

[Arpit Baldeva]

Should I file a GitHub issue for this? I am not sure what the right 
protocol is. 

Thanks. 

On Wednesday, November 23, 2016 at 1:04:07 PM UTC-8, Arpit Baldeva wrote:
>
> Thanks for the info. Typedef support would be pretty much useful for 
> regular use cases in C/C++ languages. For example, if we have 100 messages 
> that each have a game id, it'd be nice to just typedef say a uint64 to 
> GameId rather than using it explicitly in each place. This avoids errors 
> like someone using int64 accidentally in one of the messages. Another 
> example would be typedef-ing a collection like map or repeated fields which 
> are used in multiple messages. 
>
> --Arpit
>
> On Wed, Nov 23, 2016 at 11:24 AM, Adam Cozzette <acozze...@google.com> 
> wrote:
>
>> I don't think we have any specific plans to do this, but we could 
>> consider doing at some point if it would be useful. Do you have a 
>> particular use case that would benefit from support for type aliasing?
>>
>> On Mon, Nov 21, 2016 at 4:13 PM, Arpit Baldeva <abald...@gmail.com> 
>> wrote:
>>
>>> Hi,
>>>
>>> Are there any plans to introduce typedef support in the Proto files?
>>>
>>> Thanks
>>> Arpit
>>>
>>> -- 
>>> 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 group, send email to protobuf@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/protobuf.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] file import via another import

[Arpit Baldeva]

Hi,

It seems like the import directive in a proto file does not import the 
import dependencies of the file being imported. Easier to explain by 
example here.

Say you have 3 files - a.proto, b.proto, c.proto

If b.proto imports a.proto and c.proto imports b.proto, c.proto does not 
automatically import a.proto. Importing a.proto needs to be explicit. 

Is there a reason for not supporting automatic import?

Thanks. 

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] typedef support

[Arpit Baldeva]

Hi,

Are there any plans to introduce typedef support in the Proto files?

Thanks
Arpit

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] additional map keys

[Arpit Baldeva]

Hi,

Are there any plans to support 

1. Enums as keys in a map
2. Case-insensitive keys in a map 

Thanks
Arpit

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] protobuf::Any Message vs MessageLite interface

[Arpit Baldeva]

Thanks for the info.

I feel like without pack/unpack/Is method, the utility of Any will 
diminish. For example, the rpc status proto 
(https://github.com/googleapis/googleapis/blob/master/google/rpc/status.proto) 
uses repeated Any field. It'd not be possible to write code like one 
described here 
- https://developers.google.com/protocol-buffers/docs/proto3#any because 
you won't know if it is safe to convert value to a give message. I also 
came across this post after my post which marks the request as a bug 
currently - https://github.com/google/protobuf/issues/1974 

Regarding the future of GetTypeName, though it has overhead, feel like it 
could have many utilities outside of the Any support as well. I don't have 
concrete use case in mind though as I am just starting on protobuf. This 
brings another important question that I was wondering if somebody already 
has data around. There are two options for reducing code bloat. One is Lite 
and another is code_size. I understand that lite reduces code bloat by 
removing descriptors/reflections related code (thereby reducing the library 
size) and code_size reduces the code bloat by generating less code per 
message but puts descriptors/reflectors back in(shared code). And the 
recommendation is to choose code_size option if number of message are much 
higher compared to the overhead caused by the size of lib. Are there any 
benchmarks around what the size of the library is (and lite version) and 
what is the per message overhead saved by the code_size option? And the 
performance drop with code_size option?   

--Arpit



On Friday, October 7, 2016 at 10:56:49 AM UTC-7, Adam Cozzette wrote:
>
> Good question, I'm not much of a mobile developer so hopefully someone 
> with more experience there can chime in. But my thought would be that if 
> you're on mobile and need the performance of lite protos then you would 
> probably want to just read and write Any fields manually instead of using 
> the helper methods that require non-lite. If the extra boilerplate turns 
> out to be excessive, we could look into ways of updating the Any API to 
> make it a little easier to use with lite protos.
>
> On Fri, Oct 7, 2016 at 10:15 AM, Tim Kientzle  > wrote:
>
>>
>> On Oct 7, 2016, at 9:54 AM, 'Adam Cozzette' via Protocol Buffers <
>> prot...@googlegroups.com > wrote:
>>
>> Here's the thing, though: we are actually thinking about removing the 
>> MessageLite::GetTypeName method at some point in the future. Lite protos 
>> are intended primarily for mobile and so in that environment it's important 
>> to keep the binary as small as possible and also avoid including symbols in 
>> the code that's distributed, whereas currently that method requires us to 
>> generate code that includes the message type names. So I think it would be 
>> best to avoid creating another dependency on that GetTypeName() method when 
>> it might be going away in the future.
>>
>>
>> This seems to suggest that you don’t intend to support Any for mobile?
>>
>> Tim
>>
>>
>

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] protobuf::Any Message vs MessageLite interface

[Arpit Baldeva]

Hi,

I was wondering if there is any reason that Any type is implemented in 
terms of Message interface rather than MessageLite? It'd seem to me that 
all this class needs to work correctly is to use GetTypeName() on 
MessageLite interface.

My motivation is, of course, to be able to use Any type with Lite run time. 

--Arpit

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] Protobuf documentation

[Arpit Baldeva]

Okay, thanks. I did not realize the syntax bit earlier. 

I wasn't exactly compiling that sample actually. I was compiling the 
AddressBook sample that came with the pre-built bin of ProtoC (and was 
modifying it based on the sample). That file did have the syntax explicitly 
set to proto3. 

--Arpit

On Saturday, September 24, 2016 at 7:44:29 AM UTC-7, Adam Cozzette wrote:
>
> When you create a .proto file you can set either syntax = "proto2"; or syntax 
> = "proto3"; at the top, and the protobuf compiler and runtime support 
> both (as long as you're using version 3.0 or higher). We are planning to 
> support both syntaxes indefinitely, both for backward compatibility and 
> because proto2 is still a good choice for new projects that require 
> features such as unknown fields that do not exist in proto3.
>
> What was the error message you saw? I tried compiling the example just now 
> and it worked just fine, although protoc did log a warning that I needed to 
> set the syntax.
>
> On Fri, Sep 23, 2016 at 8:43 PM, Arpit Baldeva <abal...@gmail.com 
> > wrote:
>
>> As a little background, I am a new user to protobuf. Naturally, I am 
>> trying latest releases. And I see no mention on the page that this syntax 
>> may not be supported in latest version. So it ends up being odd that the 
>> first example I see does not compile with latest release :).
>>
>> --
>> 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+u...@googlegroups.com .
>> To post to this group, send email to prot...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] Protobuf documentation

[Arpit Baldeva]

As a little background, I am a new user to protobuf. Naturally, I am trying 
latest releases. And I see no mention on the page that this syntax may not be 
supported in latest version. So it ends up being odd that the first example I 
see does not compile with latest release :). 

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] Protobuf documentation

[Arpit Baldeva]

Can you elaborate what you mean by version 3 of protobuf supporting both proto 
2 and 3? I was using latest pre-built protoc compiler and it balked at this 
sample.

Arpit

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Protobuf documentation

[Arpit Baldeva]

Hi,

The documentation here 
- https://developers.google.com/protocol-buffers/docs/overview shows 
following:

optional PhoneType type = 2 [default = HOME];


However, default value can no longer be specified in proto3. I'd suggest to 
remove this and keep the documentation up to date with the current version.

Thanks. 

-- 
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 group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.