Re: [protobuf] Failed to parse map

Here's an example of how to do it: http://google3/experimental/users/acozzette/map_reflection_test.cc?rcl=158157727 It's a bit clunky because you just have to reflect on the map field like you would a repeated field, but it works. On Mon, Jun 5, 2017 at 6:08 PM, Qian Zhang

Re: [protobuf] Failed to parse map

Doing reflection on a map is a little bit tricky, but the way to do it is to treat it as a repeated field since that is how it is actually represented on the wire. A map is a stored as a repeated message field, where in each message the key is field 1 and the value is field 2. On Mon, Jun 5, 2017

Re: [protobuf] Failed to parse map

It looks to me like your JSON syntax is right. Could you post the C++ code you are using to parse the JSON file? On Fri, Jun 2, 2017 at 1:16 AM, Qian Zhang wrote: > Hi, > > I have a C++ project in which there is a .proto file, and in that file, > there is protobuf message

Re: [protobuf] Detecting unknown field in raw message

Here is a doc with the rough plan for reintroducing unknown field preservation: https://docs.google.com/document/d/1KMRX-G91Aa-Y2FkEaHeeviLRRNblgIahbsk4wA14gRk/edit?usp=sharing I am not sure what the Go API for accessing the unknown fields will look like, though. I would again recommend against

Re: [protobuf] Detecting unknown field in raw message

On Tue, May 30, 2017 at 9:06 AM, Yacov Manevich wrote: > but there are some corner cases where that would not be true >> > > Can you elaborate please? > Sure, the main thing is that protocol buffers do not have a canonical format, and there are many ways to create a valid

Re: [protobuf] Detecting unknown field in raw message

I am not that familiar with the Go implementation of protobuf, but my guess is that this would be somewhat difficult to do reliably. If you un-marshal and re-marshal the message and get a smaller size, then usually that would indicate there were some unknown fields, but there are some corner cases

Re: [protobuf] No headers included in the cmake-generate project

I'm not very familiar with CMake and so I'm not exactly sure what you're asking, but if this is easy to change then do you want to just send us a pull request? On Fri, May 26, 2017 at 7:01 AM, Dennis Cappendijk < dennis.cappend...@gmail.com> wrote: > Hi, > > I was wondering whether there was a

Re: [protobuf] Maven convert xsd to .proto

There is a project called xsd2thrift that is supposed to be able to convert XSD files to Thrift and protocol buffer schemas: http://tranchis.github.io/xsd2thrift/ I have not tried it, but it might be worth looking into. On Fri, May 26, 2017 at 2:56 AM, Kumar Rangasamy wrote:

Re: [protobuf] Re: protoc escape colon in options

I don't think there is any built-in escaping mechanism, so I think you would just have to escape the colon yourself in this case. On Wed, May 17, 2017 at 12:35 PM, David Konsumer wrote: > I guess I can just encodeURI it or something, but I hoped there might be a >

Re: [protobuf] Merging / extending 2 different Message types

I think the typical way to do this would be to just store CommonParams as a submessage in each of your request types. The one problem is that this means the fields would not be at the top-level of the JSON as you wanted to have. So I think you have to choose to either go with this approach and

Re: [protobuf] Enum values and proto3 Any types

I think the right solution for putting an enum or primitive type in an Any field would be to use a wrapper type like you mentioned. Since there's no real way to create a generic wrapper for all enums, you would probably need to create a specific wrapper for each enum you want to store in an Any

Re: [protobuf] cross compile protobuf 2.5 for arm-android

What kind of error are you getting? I have not tried cross-compiling protobuf myself but I think the --with-protoc option is the right way to go and I see you're already doing that. I'm not sure if you even need to pass the --enable-cross-compile flag. On Wed, Apr 12, 2017 at 12:55 AM, Andrea

Re: [protobuf] How to store binary file data in structure?

What does Material.dat contain? Is it a single protocol buffer or a series of protocol buffers? On Mon, Apr 10, 2017 at 11:38 PM, revanth rao wrote: > down votefavorite > > > Hi all, >

Re: [protobuf] Error in example code in Protocol Buffers Python Tutorial

Thanks for reporting this, I'll make sure to fix it next week. On Sat, Apr 8, 2017 at 2:43 AM, Hanks wrote: > According to the link: https://developers.google.com/ > protocol-buffers/docs/pythontutorial > > There is a error name defined in the .proto file, > > repeated

Re: [protobuf] Javascript with Protobuf FileDescriptorSet and what is equivalent to DynamicMessage.parse(FileDescriptor, byte[] payload) ?

Unfortunately the Javascript implementation doesn't support this kind of DynamicMessage functionality. In Javascript you can only really manipulate a protocol buffer if you have already built the generated code with protoc. On Fri, Apr 7, 2017 at 5:15 PM, Vijay Balakrishnan

Re: [protobuf] Find and set data to a sub message by message path.

One thing that might help is to use a FieldMask , since that can essentially represent the kind of path string you mentioned. You can then use FieldMaskUtil::MergeMessageTo

Re: [protobuf] Is possible to use enum from external class in .proto files?

Yes, that should work. Unless I'm misunderstanding something, you should just be able to do what Henner suggested above to accomplish this. On Fri, Apr 7, 2017 at 5:46 AM, wrote: > Hi, on the same lines need help on an idea. > > Is it possible to define my enums in

Re: [protobuf] (3.2.0) Reporting Test Suite Failure on OpenBSD

Hi Brad, thanks for reporting this. We (the protobuf-team) don't have convenient access to Solaris or OpenBSD machines to debug this ourselves, but that is interesting to know that the same issue is apparently affecting both of those platforms. Feel free to send us a pull request if you happen to

Re: [protobuf] Manual Updates/Corrections

One confusing thing about that example is that the bytes are written in hex but they look like decimal. You are right that the encoded bytes in decimal are 08, 150, 01, but in hex that is equal to 08, 96, 01. On Fri, Apr 7, 2017 at 6:42 PM, wrote: > In the encoding section of

Re: [protobuf] Segmentation fault

What protobuf version are you using? Also, are you linking against a libprotobuf that has the same version as the protoc that was used to generate your code? It's important for the version to match, because for C++ we frequently change the interface between the generated code and the runtime

Re: [protobuf] Error/problem using constants! ("Expected top-level statement (e.g. "message")")

The compiler doesn't support that syntax (DataType = DataOther | DataTest). Maybe a oneof field is what you are looking for; that would look something like this: message DataType { oneof data_type { DataOther data_other = 1; DataTest data_test = 2; } } On Mon, Mar 20, 2017 at 10:08

Re: [protobuf] extending field and message options

I believe this is to be expected, because these top-level extensions would end up having the same name. For example in C++ they would both be called example::exOptions and so there would be a conflict there. To get around this you can either give them different names or keep the same names but

Re: [protobuf] Re: Protobuf 3.2.0 + Qt 5.8 (Windows)

My first guess would be that you are somehow mixing different protobuf versions: using generated code from a new version of protoc with a protobuf runtime library of an older version. Is that true for your Windows setup? On Fri, Mar 3, 2017 at 3:19 AM, Mastic Cover wrote:

Re: [protobuf] GOOGLE_PROTOBUF_NO_THREAD_SAFETY flag not supported?

You're right, this is a known issue that GOOGLE_PROTOBUF_NO_THREAD_SAFETY is not currently working: https://github.com/google/protobuf/issues/548 On Wed, Mar 1, 2017 at 4:38 AM, Johan Nilsson wrote: > Hi, > > I am trying to build protobuf-3.1.0 with the CXXFLAG >

Re: [protobuf] Terms of Google Protobuf License

Hi Kushal, Yes, I believe you essentially just need to include the contents of our LICENSE file somewhere in the documentation or other materials provided with your library. This is according to this condition from the license: "Redistributions in binary form must reproduce the above copyright

Re: [protobuf] How to define a map option?

I believe the way to do it is something like this: option (ext) = { query: { key: "key", value: "value", } }; This works because internally maps are represented like a repeated field of messages, each containing fields called "key" and "value". On Fri, Feb 24, 2017 at

Re: [protobuf] Proposal: a mechanism to deal with sensitive/redacted fields in string output

Hi Zellyn, this sounds like a reasonable idea. As the next step could you perhaps write up a short proposal with more details on what exactly it would mean for a field to be redacted? To me it seems like the important thing would be to make sure it's clear how redacted fields are supposed to be

Re: [protobuf] Generated Javascript Protobufs and Grunt

Ok, that's good you were able to get things working with CommonJS-style imports. To parse the raw bytes into an object you will want to call MyProto.deserializeBinary(bytes). On Wed, Feb 15, 2017 at 3:42 PM, Gunnar Gissel - NOAA Federal < gunnar.gis...@noaa.gov> wrote: > FWIW, switching to

Re: [protobuf] Inconsistent ParseFromArray return value from the same message sometime return false sometime return true

The kind of log you posted is what I was talking about; these logs don't appear anywhere in /var/log but just get printed to stderr. On Wed, Feb 15, 2017 at 4:24 PM, hce h wrote: > Thanks Adam, please see embedded comments. > > On Thursday, February 16, 2017 at 5:08:59 AM

Re: [protobuf] Re: Patch to make FieldDescriptorCompare operator () const

That sounds like a good change; feel free to send out a pull request if you haven't already. On Thu, Feb 16, 2017 at 6:12 PM, 'Ross Wang' via Protocol Buffers < protobuf@googlegroups.com> wrote: > (https://github.com/google/protobuf/blob/a9ab38c17178fcedd9b46c09fa33f9 >

Re: [protobuf] allocate google protobuf C++ objects on shared memory

One thing that might help for your situation is to allocate protos on an Arena . Protocol buffers don't have support for C++ allocators but this is the closest thing to that. When you create an Arena you can pass in an initial

Re: [protobuf] Generated Javascript Protobufs and Grunt

If you could share your gruntfile that would be great. I would be interested to know in particular the protoc command used to generate the Javascript. Also it would be good to verify that the generated code for that proto did not somehow get pulled into the protobuf build and end up being part of

Re: [protobuf] Accept byte content in CodeGeneratorResponse.File

One possible work around would be to run protoc with --descriptor_set_out to just parse the .proto files and generate descriptors, and then your program could read in the descriptors without needing to use the plugin interface. Would that work well for your situation? Otherwise, your idea of using

Re: [protobuf] Inconsistent ParseFromArray return value from the same message sometime return false sometime return true

If you build in debug mode then that should enable some assertions that could potentially help. Doing that and then looking at the logs is probably the best way to get more debug information. If you could share a short snippet of code then that would help to track down the problem, too. On Tue,

Re: [protobuf] MSVC2013 linker error when attempt to run example

I'm not really familiar with MSVC but it sounds like you just need to link against the libprotobuf library. If you were able to run the unit tests successfully then you must have been able to build the library, so it should just be a matter of making sure the linker can find the built library. On

Re: [protobuf] Protobuf consistency when marshalling

Right, exactly. But this behavior is new with proto3; in proto2 unknown fields are still retained On Tue, Feb 14, 2017 at 9:35 AM, Yacov Manevich wrote: > When you say unknown fields- you mean that if hostA has an .proto schema > of version N and hostB has a .proto schema

Re: [protobuf] Protobuf consistency when marshalling

You might be able to make this work, but it can be tricky to get it right and so I wouldn't necessarily recommend it. One major problem is that maps are serialized non-deterministically because they are logically unordered. Another problem is unknown fields; if you're using proto3 then unknown

Re: [protobuf] Protobuf segmentation malloc error

The code you posted looks fine as far as I can tell, so I would guess that there is some bug occurring earlier on that just happens to produce a crash at this point. I would try running the code under Valgrind (or a similar tool like ASan

Re: [protobuf] Inconsistent ParseFromArray return value from the same message sometime return false sometime return true

If ParseFromArray() is returning different results for the same serialized proto then that does sound like a bug. Do you have an example of a proto that triggers this behavior? Also, what version of the protobuf compiler and library are you using? I suspect Debian might be packaging an older

Re: [protobuf] Compile errors protoc 3.2.0 with Qt on CentOS

It sounds like you are somehow mixing multiple versions of the protobuf library. I would guess that your system has an older version of protobuf installed by the distribution package manager and that this version is being used by QtCreator. If that's the case then you may have to tweak the

Re: [protobuf] Protobuf best practices

The style guide you linked to is the main resource I know of for recommendations on writing .proto files. About your point 1), you must use a single message type for the request--using multiple arguments or non-message types is not supported. So fortunately, your "good" example is the required

Re: [protobuf] Re: Getting IllegalAccessError in getSerializedSize()

Is it possible that you are somehow mixing protobuf versions? I would guess that your application has dependencies which are pulling in two different versions of the protobuf runtime. On Mon, Jan 30, 2017 at 7:13 AM, Marc-Antoine Bibeau < marc-antoine.bib...@appdirect.com> wrote: > Any news on

Re: [protobuf] C++ malloc error when adding a repeated message element

Sorry for taking so long to reply, somehow this slipped through my inbox. It does sound like this must have something to do with the runtime environment on your embedded board. It might be interesting to try calling malloc directly and see if you can reproduce the same kind of failure that way,

Re: [protobuf] C++ malloc error when adding a repeated message element

Could you provide some more details on what the error message looks like? I don't see anything obviously wrong with your code, so it's hard to say what the problem could be. On Fri, Jan 6, 2017 at 9:01 AM, Doug Lewis wrote: > I get a malloc error when I try to add a

Re: [protobuf] Cross compiling to ARM on X64 fails, uses ARM js_embed

Great, I'm glad it's working now. Now that you mention it I think there was another bug that js_embed was getting installed to /usr/bin, which doesn't really make sense since that program is just used as part of the build and isn't useful for anything else. I believe that is now fixed, too. On

Re: [protobuf] Cross compiling to ARM on X64 fails, uses ARM js_embed

I went ahead and merged this to master with pull request 2565 and so cross compilation should now work again. On Tue, Jan 3, 2017 at 1:29 PM, Adam Cozzette wrote: > I updated the Autotools build so that it should now correctly

Re: [protobuf] proto3 hasField return error

This behavior is to be expected, because in proto3 there is no notion of field presence for primitive type fields (more about this here ). Proto3 does not make a distinction between that field being unset and being set to its

Re: [protobuf] TextFormat Parser fails if the "&" symbol is inside a String

Could you post an example of a text-format protocol buffer that is failing to parse correctly? On Wed, Jan 4, 2017 at 1:48 AM, Apostolos Papageorgiou < apostolos.ch.papageorg...@gmail.com> wrote: > Hello, > > I am using protobuf java 3.0.0 and I am getting a "String missing ending > quote" error

Re: [protobuf] Cross compiling to ARM on X64 fails, uses ARM js_embed

I updated the Autotools build so that it should now correctly build js_embed in a form that's executable on the build machine. It is not in master yet but it is on my cross-compilation branch here: https://github.com/acozzette/protobuf/tree/cross-compilation Maxx, when you have a chance you could

Re: [protobuf] Cross compiling to ARM on X64 fails, uses ARM js_embed

I hadn't thought about the cross-compilation use case for this. It seems to me that there are a few different ways to solve this: 1. Just check well_known_types_embed.cc into Git and we can update it manually when necessary. This is probably the easiest solution but is a little bit messy since it

Re: [protobuf] How to serialize/deserialize bytes data?

It looks like you are building up a protocol buffer containing a serialized protocol buffer, which itself contains a serialized protocol buffer, which in turn contains a serialized protocol buffer, etc. Each level of nesting requires an additional two bytes: one byte for the tag number and a

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

ent or any ongoing work to support Any types with the > lite runtime? > > Best Regards, > Mohamed Koubaa > Software Developer > ANSYS Inc > > On Mon, Oct 10, 2016 at 3:00 PM, 'Adam Cozzette' via Protocol Buffers < > protobuf@googlegroups.com> wrote: > >

Re: [protobuf] Heap fragmentation due to unmarshalling

There is a discussion going on about this question on the golang-nuts mailing list in case anyone is interested: https://groups.google.com/d/msg/golang-nuts/Ahk-HunIqgs/3JTlBKRcCQAJ On Mon, Nov 28, 2016 at 7:59 AM, Devanand Reddy wrote: > Hi there, > > We are using

Re: [protobuf] Compile protobuf without pthread

I think it should be possible to build without pthreads if you just make a few minor tweaks. I fiddled around with this a little bit and got something that seems to mostly work on a branch here (though I have not really tested it): https://github.com/acozzette/protobuf/tree/without-pthread I

Re: [protobuf] typedef support

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

Re: [protobuf] Compilation warning with "arenas" option enabled for protobuf-3.1

Changchun, actually I have looked at this a little bit more and I haven't been able to convince myself for sure of whether there is a bug or not. It seems suspicious to call a method on the inactive member of a union, but on the other hand both members are POD types and the UnsafeSetDefault()

Re: [protobuf] Compilation warning with "arenas" option enabled for protobuf-3.1

I think I see what's going on. Your oneof field gets stored as a union that looks like this in the generated code: union MsgDataUnion { MsgDataUnion() {} ::google::protobuf::internal::ArenaStringPtr first_; ::google::protobuf::uint32 second_; } msg_data_; In

Re: [protobuf] Protobuf and Schema Registry

Protocol buffer schemas are represented with what are called descriptors, and descriptors themselves can be serialized as protocol buffers so that you can save them on disk or send them over the network or whatever you like. If you want to have a sort of schema registry for protocol buffers then I

Re: [protobuf] make check unit test failures and segmentation fault

Another interesting thing is that someone else reported what looks like the same segfault, but this time with MSYS2: https://github.com/google/protobuf/issues/2380 On Tue, Nov 15, 2016 at 3:54 PM, David Edge wrote: > I will try and figure out where the segfault is happening

Re: [protobuf] How to represent variable JSON object data with Proto definition

I think the problem you're running into is that unfortunately we don't currently support proto3 JSON for Javascript. Proto3 JSON is the JSON-based format that understands the special representations for well-known types such as

Re: [protobuf] Unable to perform SetExtension on 'repeated inside extensions'.

I think the MutableExtension() method is the way to go; that will return a pointer to your extension field, so in this case a pointer to DNSServerNames. Something like this should work: i->MutableExtension(dnsServerNames)->add_dnsservers("aaa"); Or you could also do it like this: DNSServerNames

Re: [protobuf] Protobuf deserialization

Serialized protocol buffers do not contain any information to allow you to determine their size, so you have to know the size you expect before you start parsing. The most common approach is to just prefix the serialized protobuf with a varint

Re: [protobuf] AIX builds fail using g++

Ok, one other thing that might be worth trying is just to see if the generic GCC implementation works for you--it seems as if that should work as long as you're using version 4.7 or higher. To do this you just have to tweak atomicops.h so that it includes atomicops_internals_generic_gcc.h. On

Re: [protobuf] AIX builds fail using g++

Thanks, Bob. I tried to reach out to one of the authors of that code but I have not heard back yet. I wonder if the problem may actually be that the assembly code is correct but that we're choosing the wrong architecture. I'm not at all familiar with AIX, but just from reading about it on its

Re: [protobuf] Compilation warning with "arenas" option enabled for protobuf-3.1

Thanks, Changchun. I have just a few more questions to try to debug the problem: - What version of g++ are you using? (g++ --version should tell you) - What architecture are you building for? - Could you send the generated code around line 266 in demo.pb.h just so that it's clear what lines the

Re: [protobuf] Compilation warning with "arenas" option enabled for protobuf-3.1

What version of g++ are you using? Also, do you have a way of determining what actual line of code the compiler is warning about there? I tried building with -Wstrict-aliasing=2 at commit df8390790a and saw a few warnings like this: ./google/protobuf/generated_message_util.h:94:66: warning:

Re: [protobuf] AIX builds fail using g++

Could you try to narrow it down to one file or the other? The atomicops.h header pulls in the right atomic operations implementation based on the platform, so with a little

Re: [protobuf] Re: Failed to compile the protobuf java example

That javac invocation is failing because it is not being given the generated code from the protobuf compiler (protoc). I would recommend building the Java examples by running "make java"; just make sure that protoc is on your PATH and that the protobuf JAR is in your CLASSPATH. On Tue, Nov 8,

Re: [protobuf] Best practices for storing .proto files

I would say it depends on what languages you're using and how your build system is set up. For any language other than C++, you have the option of just committing the protobuf generated code into source control and then you can handle it the same way you would handle any other code dependency. We

Re: [protobuf] Why Protocol Buffer(protobuf )is not in C program

We don't support C (just C++) in the main protobuf implementation, and I believe this is mostly because there has not been a lot of interest in a C implementation. However, there are some other implementations out there that support C--for example, you might want to look at upb

Re: [protobuf] Checkstyle for Protobuf

Hi Kostiantyn, Internally at Google we do have a .proto file linter, but we have not open sourced it. I believe it performs some of the checks you mentioned but not all (for example, it does not complain about required fields). Would you be interested in it if we were able to open source it? One

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

54 AM, 'Adam Cozzette' via Protocol Buffers < > protobuf@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 i

Re: [protobuf] Re: Application doesn't load on a very small number of (Windows) systems

That's good to know that you're using protocol buffers on some vintage hardware! :) I wonder if it's not the code per se that's being miscompiled for the architecture but perhaps just the serialized descriptor data that's being linked into the binary. It might be interesting to try saving the

Re: [protobuf] Re: Application doesn't load on a very small number of (Windows) systems

It sounds like the static descriptor data is somehow getting corrupted. On the affected systems does it happen reproducibly every time the application starts up? On Mon, Oct 3, 2016 at 10:54 AM, Ingmar Koecher wrote: > I can now also confirm that this problem only

Re: [protobuf] Building protobuf 3.1.0 form source files

Hi Stanislav, I believe the reason for this is that for serialization we verify that required fields are set using the GOOGLE_DCHECK macro (see here for example). That macro

Re: [protobuf] encoding rule about field_number

Just to make this more concrete let's assume we're working with a message like this: syntax = "proto2"; message MyMessage { optional fixed64 a = 16; optional int32 b = 30; }; I think the problem is that varints are encoded with the least-significant 7-bit groups first, and you got the order

Re: [protobuf] Re: Will ByteSize() return a fixed size for fixed object bype if I upgrade Google Protocol Buffer?

Yes, in your case the serialized size will remain the same because you are using simple fixed-size fields and always initializing them. There are a few things to watch out for, though: - If you use proto3 syntax, zero-valued fields will be omitted from the serialized output because zero is the

Re: [protobuf] Protobuf documentation

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

Re: [protobuf] generated java classes from .proto file doesn't compile

Hi Denis, thanks for reporting this. It seems to be a known bug: https://github.com/google/protobuf/issues/826 It comes down to the fact that in Java we represent tag numbers as ints (which are 32-bit signed values), and the protoc compiler is generating a tag number that will fit in an unsigned

Re: [protobuf] Protobuf documentation

Actually in some sense this code snippet is still up to date, because version 3.0 of protobuf supports both proto2 and proto3, and the plan is to keep supporting both for the foreseeable future. Also, if we were to update that snippet to be valid proto3 syntax then in addition to removing the

Re: [protobuf] protocol encoding

I think you must be referring to the example on varint encoding here: https://developers.google.com/protocol-buffers/docs/encoding I believe the example is correct; it's just that the ++ represents a concatenation instead of an addition. Each byte has 7 bits for storing the number (since the

Re: [protobuf] Re: protobuf-3.0 on freebsd-7

Unfortunately we don't have a compatibility matrix showing what compiler versions we support. If you have to use g++ 4.2.1 then your best bet would probably be to just try building it again and work through any errors that appear. Based on the one error you linked, it looks like the compiler is

Re: [protobuf] Detecting modifications to Protobuf messages

I have to admit that I'm not very familiar with the protocol buffers API for Python, so hopefully someone more knowledgeable can chime in. But given that Python does not have a message differencer, I think your best bet would be to try to use the reflection API to implement something similar. It

Re: [protobuf] Re: protobuf-3.0 on freebsd-7

Sowmya, my guess that your compiler version is just too old (it's from 2007). Could you try with a more recent version of g++ and let us know if that solves the problem? On Wed, Sep 14, 2016 at 10:53 PM, Sowmya Narayanam wrote: > I am using g++ (GCC) 4.2.1 20070719

Re: [protobuf] Re: Re-Parsing Received CodedMessages Over Network (Proto3)

Great, I'm glad that worked. In your C# client I think what's going on is that you're calculating the size of the message but excluding the length prefix that comes before it, so the +1 is correcting for that. In general adding 1 will not work reliably, though, since the length prefix is

Re: [protobuf] Re: Re-Parsing Received CodedMessages Over Network (Proto3)

I believe the problem you're running into is on the server side; it looks like you're parsing the size correctly but just skipping over it. Since protocol buffers are not self-delimiting, you must actually rely on the size to know how many bytes to read. I think what's probably happening is that

Re: [protobuf] Reading to the end of a protobuf.Buffer

+Ross who is the expert on protocol buffers for Go I'm not familiar with the Go implementation so I may be misunderstanding your question, but it sounds to me like you are trying to parse a protocol buffer without knowing its size. Protocol buffers are not self-delimiting, so it's not possible to

Re: [protobuf] C++ Linux Google Protocol Buffers - having trouble replicating the tutorial

I think the reason for the error you're getting is that your third command does not provide the compiled code from addressbook.proto or the libprotobuf library. I would recommend going into the examples/ directory and running "make cpp"; that will build and run the example code for you and should

Re: [protobuf] Re: Why does SerializeToArray returns true (Eventhough required fieds are missing)

Note that SerializeToArray performs an assertion to check that the all required fields are present: https://github.com/google/protobuf/blob/master/src/google/protobuf/message_lite.cc#L321 But GOOGLE_DCHECK assertions are not enabled for optimized builds since they take effect only if NDEBUG is not

Re: [protobuf] proto versioning - preventing linking at runtime to a proto version different than at buildtime

Ah, I see. In that case I think you're right that it would be best to put the symbols in separate namespaces for client and server. The protocol compiler does not have any special support for this, but you could accomplish it by having two .proto files which are identical except that one says

Re: [protobuf] proto versioning - preventing linking at runtime to a proto version different than at buildtime

I sounds to me like this symbol duplication is causing a C++ ODR (one-definition rule) violation, which could explain the crashes you have seen. I would try moving the compiled proto symbols into a separate library and have both the client and server libs depend on that same library so that there

Re: [protobuf] What tool does Google use to generate the webpages for the protobuf C++ api?

I'm glad you like the documentation! I asked around and it appears that it is in fact Doxygen with a custom transformation applied to it, though I don't really know the details beyond that. On Tue, Jun 7, 2016 at 12:21 PM, wrote: > One of the things I love about using

Re: [protobuf] Proto 3... release date?

We still can't make any promises about when 3.0 will be officially released, but a rough ETA would be the end of next month (July). On Fri, Jun 10, 2016 at 8:41 AM, João Peixoto wrote: > I was just wondering if there has been an update here? > > We are starting a new

Re: [protobuf] template/type deduction and 'oneof' in message

I don't think this kind of type deduction is possible here, because the type of the oneof can't be known until runtime and so the compiler has no way of knowing which function to select. Alex, I believe the convert example at the top of your link works but only because the caller explicitly

Re: [protobuf] protobuf-dt required password from eclipse marketplace

I've just now heard that the problem has been fixed. Yan and workingmeloen, could you try again and let me know if you run into any more problems? On Wed, May 11, 2016 at 5:21 AM, wrote: > > Me and a collegue have encountered this exact problem too, looking forward > to

Re: [protobuf] Repeated Enums

I've added something to the Go docs to clarify this. There might be a delay before it's live on developers.google.com, though. On Fri, May 6, 2016 at 4:43 PM, Adam Cozzette wrote: > Thanks for reporting this hole in the documentation; I'll see about > updating the Go

Re: [protobuf] protobuf-dt required password from eclipse marketplace

Thanks for reporting this, Yan. I've passed this along to the team that maintains the plugin; they were able to reproduce the problem and are working on a fix now. On Sun, May 8, 2016 at 6:00 AM, Yan Yan wrote: > >

Re: [protobuf] Decimal in json?

+jonskeet On Fri, May 6, 2016 at 7:34 PM, Ray Rizzuto Jr wrote: > Well, it might be as simple as how it is represented in .Net: > http://csharpindepth.com/Articles/General/Decimal.aspx > > Other languages might have different representation, and ranges, so > whatever is

Re: [protobuf] Decimal in json?

A decimal type sounds like potentially a good candidate for becoming a well-known type with a custom JSON representation. There's a StackOverflow discussion

Re: [protobuf] Proto3 Storing UUID

The bytes type sounds like a good choice to me. I could also imagine using a pair of fixed64 fields if you want to avoid having to validate the length of the byte string. On Thu, Apr 28, 2016 at 10:39 PM, Osman Ali wrote: > Looking use a 128 bit uuid according to rfc4122.

<    1   2   3   4   5   >