[protobuf] Issue 682 in protobuf: Windows phone 8.1 problem
Status: New Owner: liuj...@google.com Labels: Type-Defect Priority-Medium New issue 682 by dobba...@gmail.com: Windows phone 8.1 problem https://code.google.com/p/protobuf/issues/detail?id=682 I use protobuf in winrt app for Windows and windows phone. I got this message when build for ARM: Host architecture was not detected as supported by protobuf The device is Nokia Lumia 1020. My OS is Windows 8.1, Visual Studio 2013 When is build for x86(run on emulator) everything is fine. What is the expected output? What do you see instead? Thank's! -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- 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] Passing messages without a compiled proto
Is it possible, given a proto file, but without compiling it(protoc), to use the proto file directly to be able to load data? In other words parsing the proto file at run time and generating a reflection interface or something such that a tool may read the messages with just the proto file without having to generate the code with protoc ? -- 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: Issue 682 in protobuf: Windows phone 8.1 problem
Updates: Status: WontFix Comment #1 on issue 682 by xiaof...@google.com: Windows phone 8.1 problem https://code.google.com/p/protobuf/issues/detail?id=682 Hi dobballa, we moved to github not very long ago. Could you file this issue on our github site? https://github.com/google/protobuf/issues Also as we don't have such a testing environment as yours, we'll need users' patch to fix this problem. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- 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] Protobuf Buffers v3.0.0-alpha-1
Hi all, I just published protobuf v3.0.0-alpha-1 on our github site: https://github.com/google/protobuf/releases/tag/v3.0.0-alpha-1 This is the first alpha release of protobuf v3.0.0. In protobuf v3.0.0, we will add a new protobuf language version (aka proto3) and support a wider range of programming languages (to name a few: ruby, php, node.js, objective-c). This alpha version contains C++ and Java implementation with partial proto3 support (see below for details). In future releases we will add support for more programming languages and implement the full proto3 feature set. Besides proto3, this alpha version also includes two other new features: map fields and arena allocation. They are implemented for both proto3 and the old protobuf language version (aka proto2). We are currently working on the documentation of these new features and when it's ready it will be updated to our protobuf developer guide https://developers.google.com/protocol-buffers/docs/overview. For the time being if you have any questions regarding proto3 or other new features, please post your question in the discussion group. CHANGS === Version 3.0.0-alpha-1 (C++/Java): General * Introduced Protocol Buffers language version 3 (aka proto3). When protobuf was initially opensourced it implemented Protocol Buffers language version 2 (aka proto2), which is why the version number started from v2.0.0. From v3.0.0, a new language version (proto3) is introduced while the old version (proto2) will continue to be supported. The main intent of introducing proto3 is to clean up protobuf before pushing the language as the foundation of Google's new API platform. In proto3, the language is simplified, both for ease of use and to make it available in a wider range of programming languages. At the same time a few features are added to better support common idioms found in APIs. The following are the main new features in language version 3: 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. 2. Removal of unknown fields. 3. Removal of extensions, which are instead replaced by a new standard type called Any. 4. Fix semantics for unknown enum values. 5. Addition of maps. 6. Addition of a small set of standard types for representation of time, dynamic data, etc. 7. A well-defined encoding in JSON as an alternative to binary proto encoding. This release (v3.0.0-alpha-1) includes partial proto3 support for C++ and Java. Items 6 (well-known types) and 7 (JSON format) in the above feature list are not implemented. A new notion syntax is introduced to specify whether a .proto file uses proto2 or proto3: // foo.proto syntax = proto3; message Bar {...} If omitted, the protocol compiler will generate a warning and proto2 will be used as the default. This warning will be turned into an error in a future release. We recommend that new Protocol Buffers users use proto3. However, we do not generally recommend that existing users migrate from proto2 from proto3 due to API incompatibility, and we will continue to support proto2 for a long time. * Added support for map fields (implemented in C++/Java for both proto2 and proto3). Map fields can be declared using the following syntax: message Foo { mapstring, string values = 1; } Data of a map field will be stored in memory as an unordered map and it can be accessed through generated accessors. C++ * Added arena allocation support (for both proto2 and proto3). Profiling shows memory allocation and deallocation constitutes a significant fraction of CPU-time spent in protobuf code and arena allocation is a technique introduced to reduce this cost. With arena allocation, new objects will be allocated from a large piece of preallocated memory and deallocation of these objects is almost free. Early adoption shows 20% to 50% improvement in some Google binaries. To enable arena support, add the following option to your .proto file: option cc_enable_arenas = true; Protocol compiler will generate additional code to make the generated message classes work with arenas. This does not change the existing API of protobuf messages and does not affect wire format. Your existing code should continue to work after adding this option. In the future we will make this option enabled by default. To actually take advantage of arena allocation, you need to use the arena APIs when creating messages. A quick example of using the arena API: {
Re: [protobuf] Protobuf Buffers v3.0.0-alpha-1
Feng Xiao, I have some questions: 1. does protobuf3 will include golang compiler? 2. does protobuf3 have a spec doc (link?) ? Thanks. 2014-12-11 12:51 GMT+08:00 Feng Xiao xiaof...@google.com: Hi all, I just published protobuf v3.0.0-alpha-1 on our github site: https://github.com/google/protobuf/releases/tag/v3.0.0-alpha-1 This is the first alpha release of protobuf v3.0.0. In protobuf v3.0.0, we will add a new protobuf language version (aka proto3) and support a wider range of programming languages (to name a few: ruby, php, node.js, objective-c). This alpha version contains C++ and Java implementation with partial proto3 support (see below for details). In future releases we will add support for more programming languages and implement the full proto3 feature set. Besides proto3, this alpha version also includes two other new features: map fields and arena allocation. They are implemented for both proto3 and the old protobuf language version (aka proto2). We are currently working on the documentation of these new features and when it's ready it will be updated to our protobuf developer guide https://developers.google.com/protocol-buffers/docs/overview. For the time being if you have any questions regarding proto3 or other new features, please post your question in the discussion group. CHANGS === Version 3.0.0-alpha-1 (C++/Java): General * Introduced Protocol Buffers language version 3 (aka proto3). When protobuf was initially opensourced it implemented Protocol Buffers language version 2 (aka proto2), which is why the version number started from v2.0.0. From v3.0.0, a new language version (proto3) is introduced while the old version (proto2) will continue to be supported. The main intent of introducing proto3 is to clean up protobuf before pushing the language as the foundation of Google's new API platform. In proto3, the language is simplified, both for ease of use and to make it available in a wider range of programming languages. At the same time a few features are added to better support common idioms found in APIs. The following are the main new features in language version 3: 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. 2. Removal of unknown fields. 3. Removal of extensions, which are instead replaced by a new standard type called Any. 4. Fix semantics for unknown enum values. 5. Addition of maps. 6. Addition of a small set of standard types for representation of time, dynamic data, etc. 7. A well-defined encoding in JSON as an alternative to binary proto encoding. This release (v3.0.0-alpha-1) includes partial proto3 support for C++ and Java. Items 6 (well-known types) and 7 (JSON format) in the above feature list are not implemented. A new notion syntax is introduced to specify whether a .proto file uses proto2 or proto3: // foo.proto syntax = proto3; message Bar {...} If omitted, the protocol compiler will generate a warning and proto2 will be used as the default. This warning will be turned into an error in a future release. We recommend that new Protocol Buffers users use proto3. However, we do not generally recommend that existing users migrate from proto2 from proto3 due to API incompatibility, and we will continue to support proto2 for a long time. * Added support for map fields (implemented in C++/Java for both proto2 and proto3). Map fields can be declared using the following syntax: message Foo { mapstring, string values = 1; } Data of a map field will be stored in memory as an unordered map and it can be accessed through generated accessors. C++ * Added arena allocation support (for both proto2 and proto3). Profiling shows memory allocation and deallocation constitutes a significant fraction of CPU-time spent in protobuf code and arena allocation is a technique introduced to reduce this cost. With arena allocation, new objects will be allocated from a large piece of preallocated memory and deallocation of these objects is almost free. Early adoption shows 20% to 50% improvement in some Google binaries. To enable arena support, add the following option to your .proto file: option cc_enable_arenas = true; Protocol compiler will generate additional code to make the generated message classes work with arenas. This does not change the existing API of protobuf messages and does not affect wire format. Your existing code should continue to work after