Re: [protobuf] Re: How to check empty message object
and these hazzers logics have to go away. Google says, we will continue to support proto2 for a long time. True, but it also means that if we ever want to use proto3 features (which we do), then we have to trade away presence logic for primitive fields. This is an unfortunate decision to have to make. -- 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 http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
[protobuf] Re: How to use protoc.exe in Windows for eclipse luna?
We happen to use the protobuf-dt https://code.google.com/p/protobuf-dt/ plugin for Eclipse. The project (open-source) is owned by two Google engineers, but it hasn't been updated in a while - it *really* needs to be updated. It can be configured to compile your .proto files (using protoc.exe) and place the generated files in a location of your choosing. It also supports editing and syntax highlighting of .proto files, which is really nice. - You can seek additional help at the protobuf-dt google group https://groups.google.com/forum/#!forum/protobuf-dt. You can always compile your .proto files manually outside of Eclipse too, or write a script for it. -- 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 http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
[protobuf] Re: How to check empty message object
Open question to everyone. I'm curious. In all of your use-cases with protobuf, how often do you find yourself using has_foo() (a.k.a. hazzers) for primitive fields? We use them almost everywhere because, for example, it is a very useful way of error-checking requests on the server sent from our client code on mobile devices. Maybe we're just outliers. Google's stated reason for getting rid of presence logic is below (bolding by me): *It's believed* that most users don't use the field presence logic much and for those who need this feature adding a bool field is an easy workaround. ... It would definitely *not* be an easy workaround for us given how much we rely on presence logic. Are we in the minority? -- 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 http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
[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 proto3 significantly easier to implement with open struct representations, as in languages like Android Java, Objective C, or Go. -- 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 http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
[protobuf] Re: Protobuffers for API
In this context, it's the Parameter Object Patternhttp://refactoring.com/catalog/introduceParameterObject.html . I am pushing our team toward doing this *exact* thing for our client-side library (Android, iOS, WP8, Javascript). The only objection that I keep hearing from team members is that users of the library *might* not be familiar with using protobufs. That may or may not be something to consider for your API. I personally believe that it's only a minor issue. Will your API be a library API (for code running on the same machine), or a backend API, or something else? We already do this internally (i.e. hidden API) for communication between our backend and our native mobile clients. Protobufs work beautifully for that use-case. -- 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 http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
[protobuf] ByteString using N bytes from an InputStream?
Greetings all, We are using version 2.5. What is the most efficient way (*i.e.* single copy operation, no extra byte arrays) to construct a ByteString from a specific number of bytes in an InputStream? The various versions of ByteString.readFrom() drain the stream completely, which is not what we need; any data past *N* bytes should remain in the stream. The ByteString.readChunk() method looks like it will work if we simply give it * N* as the chunkSize parameter. Unfortunately, ByteString.readChunk() is declared private, so that method is not currently an option. Is there another option that I just haven't found in the source code yet? (Thanks for taking the time to read this question.) -- 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 http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/groups/opt_out.
Re: [protobuf] ByteString using N bytes from an InputStream?
Hi Feng Xiao! Thanks for the response. That's actually our backup plan. We were hoping to avoid it, though, since the wrappers would each contain an extra copy of the data internally. Our ideal case is for the data to get copied in a single step directly from an InputStream to a ByteString with no intermediate copies along the way. Question: You would know best... Would the safety of ByteStrings be preserved if the readChunk() method were to be made public? If so, I'll open a feature request on the issue tracker. On Monday, August 5, 2013 7:32:49 PM UTC-4, Feng Xiao wrote: How about create an wrapper InputStream that only reads N bytes from the original InputStream and provide the wrapper to BytesString.readFrom()? -- 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 http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/groups/opt_out.
Re: [protobuf] ByteString using N bytes from an InputStream?
... Actually, I just now took a closer look at the readChunk() method. Even that method makes an internal copy, so it looks like readChunk() isn't what we are looking for after all. Hmmm. On Tuesday, August 6, 2013 12:28:56 AM UTC-4, V.B. wrote: Hi Feng Xiao! Thanks for the response. That's actually our backup plan. We were hoping to avoid it, though, since the wrappers would each contain an extra copy of the data internally. Our ideal case is for the data to get copied in a single step directly from an InputStream to a ByteString with no intermediate copies along the way. Question: You would know best... Would the safety of ByteStrings be preserved if the readChunk() method were to be made public? If so, I'll open a feature request on the issue tracker. -- 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 http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/groups/opt_out.
[protobuf] Re: Plugin for Obj-c
+1 I run a project where data is passed between Android, iOS, and Windows Phone 8, with an AppEngine backend and a GWT frontend. We absolutely love using protocol buffers, but the glaring hangup we keep running into is the lack of an iOS PB compiler. (That, and GWT doesn't have protocol buffer support yet.) -- 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 http://groups.google.com/group/protobuf?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
