protocol-buffers

I've seen two different ways of declaring an gRPC service using Protobuf v3. Some code has the rpc line end with a semicolon (such as the current proto3 documentation): service SearchService { rpc Search (SearchRequest) returns (SearchResponse); } Other code has the rpc line end with {} : service Greeter { rpc SayHello (HelloRequest) returns (HelloReply) {} } Both of these compile with the protoc v3.0.0-alpha-2 compiler and produce the same (go) code. What is the difference between the two syntaxes? Nothing, really; they are equivalent. The {} syntax is used when there are options. If you don

I have access to a large IBM Power8 machine, and would like to install TensorFlow on it. Naturally, I tried the quick pip install, but it failed: sudo pip install https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-0.6.0-cp27-none-linux_x86_64.whl tensorflow-0.6.0-cp27-none-linux_x86_64.whl is not a supported wheel on this platform. Storing debug log for failure in /home/pv/.pip/pip.log Unfortunately, pip.log cotains little useful info. /usr/bin/pip run on Sat Feb 6 17:29:34 2016 tensorflow-0.6.0-cp27-none-linux_x86_64.whl is not a supported wheel on this platform. Exception

Let's say I have 2 Protobuf-Messages, A and B. Their overall structure is similar, but not identical. So we moved the shared stuff out into a separate message we called Common. This works beautifully. However, I'm now facing the following problem: A special case exists where I have to process a serialized message, but I don't know whether it's a message of type A or type B. I have a working solution in C++ (shown below), but I failed to find a way to do the same thing in Python. Example: // file: Common.proto // contains some kind of shared struct that is used by all messages: message Common {

I'm currently getting an error which points me to these lines in the header file produced by protoc: #if 2006001 < GOOGLE_PROTOBUF_MIN_PROTOC_VERSION #error This file was generated by an older version of protoc which is #error incompatible with your Protocol Buffer headers. Please #error regenerate this file with a newer version of protoc. #endif But my protoc version matches the one above: protoc --version libprotoc 2.6.1 What am I doing wrong? Originally my protoc version was 3.0.0 then reinstalled it by syncing back to 2.6.1 and doing the steps; make distclean, ./configure , make, make

protocol buffer say it can contain any arbitrary sequence of bytes . but if my data contain '\0' ,how protocol buffer can encode my whole data from a string variable. The C++ implementation of protocol buffers returns the byte and string types as std::string . This structure contains a length function telling you how long the corresponding data is (as well as the data itself.) Thus there is no special significance of embeded \0 characters. The setting functions accept a string too, or there are versions that accept a buffer and length. If you want to set a field you can just do this: pb.set

For a simple proto file: message Person { required int32 id = 1; required string name = 2; optional string email = 3; } It's been compiled by protoc.exe and the results are used in an also simple test project, which basically does nothing but including the protoc generated files. I'm using the msvc10 to build the test project (x64), then it gave me a lot of warning: Warning 1 warning C4244: 'return' : conversion from '__int64' to 'int', possible loss of data D:\Work\protobuf-trunk\src\google\protobuf\descriptor.h 1441 1 testProtobuf ... Warning 11 warning C4267: 'argument' : conversion from

Is it possible to decompile a string containing Protocol Buffers descriptor back to .proto file? Say I have a long string like \n\file.proto\u001a\u000ccommon.proto\"\u00a3\u0001\n\nMsg1Request\u0012\u0017\n\u0006common\u0018\u0001 ... etc. I need to restore .proto, not necessary exactly as it was but compilable. Yes it should be possible to get some thing close get original definition. I do not know of any existing code to do it (hopefully some one else will). Hava a look at how protocol buffers itself handles the String. Basically convert the string to bytes (using charset="ISO-8859-1" in

I’m talking about the audio features dataset available at https://research.google.com/audioset/download.html as a tar.gz archive consisting of frame-level audio tfrecords. Extracting everything else from the tfrecord files works fine (I could extract the keys: video_id, start_time_seconds, end_time_seconds, labels), but the actual embeddings needed for training do not seem to be there at all. When I iterate over the contents of any tfrecord file from the dataset, only the four keys video_id, start_time_seconds, end_time_seconds, and labels, are printed. This is the code I'm using: import