Re: [protobuf] Re: protobuf js custom options
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)
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
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
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?
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 options, visit https:
Re: [protobuf] Next release tentative due date(3.4.0)
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 > 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)
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
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
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
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
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 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 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 >>> 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 >>>> 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
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 > 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 >> 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
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.
Re: [protobuf] typedef support
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 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 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] typedef support
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
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
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
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
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 > 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
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
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
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.