Re: [protobuf] Yet Another Protocol Buffers Implementation for C
David,
Am 25.07.2015 um 07:03 schrieb David Rogers predictivestatm...@gmail.com:
Nanopb has a heavier interface for including sub-messages. Here's an
example, from their union structure:
// This is an example of how to handle 'union' style messages
// with nanopb, without allocating memory for all the message types.
//
// There is no official type in Protocol Buffers for describing unions,
// but they are commonly implemented by filling out exactly one of
// several optional fields.
message MsgType1 {
required int32 value = 1;
}
message MsgType2 {
required bool value = 1;
}
message MsgType3 {
required int32 value1 = 1;
required int32 value2 = 2;
}
message UnionMessage {
optional MsgType1 msg1 = 1;
optional MsgType2 msg2 = 2;
optional MsgType3 msg3 = 3;
}
it's encoded with:
/* This function is the core of the union encoding process. It handles
* the top-level pb_field_t array manually, in order to encode a correct
* field tag before the message. The pointer to MsgType_fields array is
* used as an unique identifier for the message type.
*/
bool encode_unionmessage(pb_ostream_t *stream, const pb_field_t
messagetype[], const void *message)
{
const pb_field_t *field;
for (field = UnionMessage_fields; field-tag != 0; field++)
{
if (field-ptr == messagetype)
{
/* This is our field, encode the message using it. */
if (!pb_encode_tag_for_field(stream, field))
return false;
return pb_encode_submessage(stream, messagetype, message);
}
}
/* Didn't find the field for messagetype */
return false;
}
Their low-level code is necessary because Usually, nanopb would allocate
space to store all of the possible messages at the same time, even though at
most one of them will be used at a time.
My library would encode such a thing by calling the top-level
(auto-generated) function:
buf = UnionMessage_to_string(len, (MY_UnionMessage *)test);
and providing copy functions for each message. The auto-generated example
code to use the interface is below:
void protowr_MsgType1(MsgType1 *out, MY_MsgType1 *a) {
out-value = a-value;
}
void protowr_MsgType2(MsgType2 *out, MY_MsgType2 *a) {
out-value = a-value;
}
void protowr_MsgType3(MsgType3 *out, MY_MsgType3 *a) {
out-value1 = a-value1;
out-value2 = a-value2;
}
// of course, the programmer would modify this to a case() statement.
void protowr_UnionMessage(UnionMessage *out, MY_UnionMessage *a) {
out-has_msg1 = a-has_msg1;
if(a-has_msg1) {
out-msg1 = a-msg1;
}
out-has_msg2 = a-has_msg2;
if(a-has_msg2) {
out-msg2 = a-msg2;
}
out-has_msg3 = a-has_msg3;
if(a-has_msg3) {
out-msg3 = a-msg3;
}
}
There is no dealing with the byte-level encoding at this level, only copying
between a shallow parsed format and your own output data structure, one
message at a time. It also doesn't litter message-specific field tags or
names anywhere - only high-level, per-message encoding/decoding functions. I
don't know if nanopb does this, but some implementations do.
Hope that helps,
not yet, as I do not fully understand the point you are making
Is the type/name specific per-field/per-message accessors?
I note one of the key advantages of nanob is - it can get by without
malloc/free support meaning it can live in very restricted environments like
embedded/bare metal or even in-kernel, which explains some of the API choices
- Michael
~ David.
On 7/25/15 12:40 AM, Michael Haberler wrote:
Hi David,
Am 23.07.2015 um 22:47 schrieb David Rogers predictivestatm...@gmail.com
:
sprotoc - short for stack protocol buffer compiler is a C-code generator
for protocol buffers.
It lives at:
https://github.com/frobnitzem/sprotoc
I coded it up a year ago and have been using it happily since.
What makes it unique is the ability to write your own copy in/out functions
for each message type so that you aren't stuck with creating a copy of a
large recursive data structure.
It generates example copy functions so you can get going without reading
excessive documentation.
how is that different from nanopb (http://koti.kapsi.fi/~jpa/nanopb/
) ?
- Michael
--
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
Re: [protobuf] Yet Another Protocol Buffers Implementation for C
Hi David, Am 23.07.2015 um 22:47 schrieb David Rogers predictivestatm...@gmail.com: sprotoc - short for stack protocol buffer compiler is a C-code generator for protocol buffers. It lives at: https://github.com/frobnitzem/sprotoc I coded it up a year ago and have been using it happily since. What makes it unique is the ability to write your own copy in/out functions for each message type so that you aren't stuck with creating a copy of a large recursive data structure. It generates example copy functions so you can get going without reading excessive documentation. how is that different from nanopb (http://koti.kapsi.fi/~jpa/nanopb/) ? - Michael -- 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. -- 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.
Re: [protobuf] XML to Protocol Buffers converter
Am 16.07.2015 um 11:52 schrieb Aravinth Veeramuthu aravinth.veeramu...@vembu.com: How to convert the XML data into the Protocol buffer format in c++??? https://github.com/search?utf8=%E2%9C%93q=xml+protobufref=simplesearch -- 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. -- 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.
Re: [protobuf] gRPC: Google's RPC framework that works with Protocol Buffers
Feng, Am 11.03.2015 um 02:08 schrieb Feng Xiao xiaof...@google.com: In case you are not yet aware of: Google has open-sourced its own RPC framework, named gRPC, about two weeks ago. gRPC website: http://www.grpc.io/ It's basically Google's official RPC implementation for Protocol Buffers (in particular for proto3), but released as a separate project. For those of you who are interested in proto3, gRPC should be of interest to you as well :) great to see the coming out of the RPC part of protobuf! - it seems gPRC is 'the full stack' resting on HTTP2 TCP, or is the transport intended to be replaceable/pluggable? - does HTTP2 replace Websockets (which would have been my choice, but I'm not up to speed on the transport du jour) - is there any relation to RPCZ (https://github.com/thesamet/rpcz)? thanks! Michael ps: I'd be interested in hearing if anybody planning to plug this into a zeroMQ/protobuf stack psps: we've been using a raw zeroMQ/protobuf stack without protoPC due to licensing restrictions on RPCZ (Apache license incompatible with GPL2) -- 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. -- 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.
Re: [protobuf] Protobuf Buffers v3.0.0-alpha-1
Hallo Feng,
Am 11.12.2014 um 05:51 schrieb 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
a question on structuring web applications further downstream:
you mention node.js and JSON (de)serialisation
reading between the lines this would suggest to me a typical protobuf
application talking to a web client would talk JSON-serialized protobuf (maybe
over a websocket stream)
I've used this scheme and while JSON is easy for browser js engines, there are
downsides; for instance, (de)serializing doubles from/to JSON usually creates
conversion/rounding fuzz - that precludes signing a protobuf object in binary
representation because the signature generally wont be valid after JSON
conversion. Looser type checking is another drawback.
That is why I found an end-to-end binary protobuf transfer and client-side js
bindings along the lines of https://github.com/dcodeIO/ProtoBuf.js more robust
what's the grand vision here - how are web apps going to talk to protobuf API's
server-side?
thanks in advance,
Michael
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. 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
[protobuf] time to fork a community-supported protobuf?
Am 21.04.2014 um 17:11 schrieb proto...@googlecode.com: Comment #11 on issue 434 by tom.ritc...@gmail.com: With PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp, parent object deleted while child still exists: causes segmentation fault http://code.google.com/p/protobuf/issues/detail?id=434 Another xoogler here. Unfortunately convinced my team to use protocol buffers and now we run into this. An ETA would be really handy... Considering that someone went to the work of finding the one-line patch that solves this, and that Google has not found the time to address it in eighteen months, perhaps it's the case that Google should relinquish control of this project that they clearly no longer have the time to support? Neither fixing this or allowing others to fix this is very frustrating... I think one should recognize the fact the public edition, and feeding back from there, ranks less than top in Google priorities. While I am thankful this has been made public, I am getting concerned about the viability of this code base for outside projects which must rely on a working patch cycle. This suggests it may time to consider to fork a community-supported protobuf, since the current approach is a bit too dangerous for folks relying on this code base as maintained in the current style. When we get around to it, and no, we dont merge that patch is inadaequate for many relying on this. I'd think there's a large enough user base behind this to make such an effort viable. - Michael Haberler -- 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.
Re: [protobuf] python proto optimizations
Am 27.02.2014 um 01:11 schrieb patr...@dropbox.com:
Hey guys,
I wrote two different patches which optimize python proto performance. Both
patches are running in production at Dropbox.
I would love to see these patches being reintegrated.
Q: what is the relation to Python C bindings, if any?
regards, Michael
What is the best way to upstream these changes?
Patrick
Patch #1. Python message patch
(https://www.dropbox.com/s/q0y44ypti0by779/protobuf-2.5.0.patch1):
Changes:
- precompute various varint tables
- don't use proto's ByteSize function for serialization
- simplified some code (got rid of the listener)
- got rid of StringIO
Internal benchmark:
- random repeated int32s - ~18% faster
- random repeated int64s - ~20% faster
- random repeated strings - 27% faster
- random repeated bytes - 27% faster
- repeated message with each with a single random string - ~20% faster
NOTE:
- predefined_varints.py is generated by generate_predefined_varints.py
Patch #2. C++ experimental binding patch
(https://www.dropbox.com/s/5nr0v76nfraaxif/protobuf-2.5.0.patch2):
Changes:
- fixed memory ownership / dangling pointer (see NOTE #1 for known issues)
1. inc ref count parent message when accessing a field,
2. a cleared field's is freed only when the parent is deleted
- fixed MakeDescriptor to correctly generating simple proto (see NOTE #2)
- fixed MergeFrom to not crash on check failure due to self merge
- fixed both repeated and non-repeated field clearing
- modified varint deserialization to always return PyLong (to match existing
python implementation)
- always mark message as mutate when extending a repeated field (even when
extending by an empty list)
- deleted/updated bad tests from the protobuf test suite
Internal benchmark (relative to the first patch):
- 30x faster for repeated varints
- 8x faster for repeated string
- 6x faster for repeated bytes
- 26x speed up for repeated nested msg
NOTE:
1. In the current implementation, a new python object is created each time a
field is accessed. To make this 100% correct, we should return the same
python object whenever the same field is accessed; however, I don't think the
accounting overhead is worth it. Implications due to the current
implementation:
- repeatedly clearing / mutating the same message can cause memory blow up
- There's a subtle bug with clearing / mutating default message fields:
This is correct. Holding a reference to a MUTATED field X, then clearing
the parent, then mutate X. e.g.,
child = parent.optional_nested_msg
child.field = 123 # this mutates the field
parent.Clear()
child.field = 321
assert not parent.HasField('child') # passes
This is incorrect. Holding a reference to a UNMUTATED field X, then
clearing the parent, then mutate X.
child = parent.optional_nested_msg
parent.Clear()
child.field = 321 # this inadvertently causes parent to generate a
different empty msg for optional_nested_msg.
assert not parent.HasField('optional_nested_msg') # fail
Luckily, these access patterns are extremely rare (at least at dropbox).
2. I wrote a fully functional MakeDescriptor for c++ protos when I was at
google. Talk to the F1 team (specifically Bart Samwel / Chad Whipkey) if
you're interested in upstreaming that to the opensource community.
--
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.
--
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] pb2 / json conversion and back
this code has been rewritten from scratch because of licensing issues and is now MIT licensed https://github.com/shramov/json2pb (note name change; both C++ and Python versions included) would it be possible to add a link in the 'Third Party resources' section ? - Michael Am 11.06.2013 um 20:42 schrieb Michael Haberler mai...@mah.priv.at: this code does pb2json conversion and back; repeated message handling in json2pb is still WIP but the rest works fine: https://github.com/shramov/pb2json I've contacted the original author (renenglish) to clarify the license status - Michael -- 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. -- 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.
[protobuf] pb2 / json conversion and back
this code does pb2json conversion and back; repeated message handling in json2pb is still WIP but the rest works fine: https://github.com/shramov/pb2json I've contacted the original author (renenglish) to clarify the license status - Michael -- 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.
[protobuf] proto - .c/.cc/.h/.py dependencies Makefiles
curious - how would one best handle dependencies in Makefiles between .proto files, other .proto references and the build artefacts? the only way I see so far is manual dependency tracking or am I overlooking some tool/tool option to generate those with say 'gcc -MD' ? - Michael -- 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.
Re: [protobuf] Issue 515 in protobuf: More intelligent enums
Am 27.05.2013 um 22:07 schrieb proto...@googlecode.com:
Status: New
Owner: liuj...@google.com
Labels: Type-Defect Priority-Medium
New issue 515 by peterhan...@yahoo.com: More intelligent enums
http://code.google.com/p/protobuf/issues/detail?id=515
(this is a RFE, not a defect)
Currently if you define:
enum Foo {
NONE=0;
FOO1=1;
}
enum Bar {
NONE=0;
BAR1=1;
}
it won't compile because the same enum value, NONE, is used in two different
enums within the same proto file.
This is by design: Protobuf recognizes that the above construct will not work
in C++ and therefore rejects it (no matter the output language). See Issue
#12. The reason for the name collision is due to the somewhat odd
implementation of enums in C++.
For other languages, like Java, there is no name conflict in the generated
code so it is unfair to punish all other languages for the shortcomings of
C++.
The existing restriction is extremely annoying as there aren't really any
good alternatives. Each alternative has its own problems. (alternatives would
be : use one proto file per enum, embed enums inside a message, etc)
Let's be constructive: The big question is how to improve on this without
breaking the millions of lines of C++ code that depend on the existing
behavior?
This group discussion has the solution:
https://groups.google.com/forum/#!topic/protobuf/d-AqClgnDKM (alopecoid's
suggestion is the one I like, it is clean, clear and doesn't break any
existing code)
I'll just re-iterate alopecoid's suggestion here.
The basic suggestion is to add an option to enums:
enum Foo {
option use_namespace = true;
NONE=0;
FOO1=1;
}
enum Bar {
option use_namespace = true;
NONE=0;
BAR1=1;
}
This option would default to 'false', meaning the exact behavior of protobuf
compiler today. However if the option is true the compiler will no longer
fault on the above construct (for any output language). For C++ it will then
generate C++ code like this:
namespace Foo {
enum Enum {
NONE = 0;
FOO1 = 1;
}
}
namespace Bar {
enum Enum {
NONE = 0;
BAR1 = 1;
}
}
and the enums would then be referenced in C++ code like Foo::NONE and
Bar::NONE.
For other languages that also use unscoped enums (like C++) the generated
code for such language will have to find their own solution to the problem.
(are there any such languages at all?)
For languages that use scoped enums (most languages that I can think of,
example: Java) the option would have no effect. It is the same code being
generated in both cases.
I like the suggestion because it doesn't break any existing code.
I like it too, also because it resolves an issue I have with wrapping existing
objects - assume you have some C typedefs
typedef enum { FOO=0, BAR=1 } obj1_t;
typedef enum { BAZ=2, XXX=3 } obj2_t;
then I cant have a proto enum like so:
enum ObjTypes {
FOO = 0;
BAR = 1;
BAZ = 2;
XXX = 3;
}
without renaming the enums in the proto enum; the namespace proposal would
solve that issue with no apparent downside
- Michael
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
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.
Re: [protobuf] is protobuf the right choice in this case?
Am 20.04.2013 um 14:17 schrieb balche8 anibal.cheha...@gmail.com: Hi all, I'm working on a project that involves two layers: one is written in C++ and the other one in Javascript. The C++ layer contains the model of the application in form of a tree in a similar way as HTML does (nothing really complicated, just elements with attributes). The interaction between these two layers is done using JSON. We manually implement the classes that serialize/deserialize JSON requests/responses and it is becoming a waste of time (plus the impact in maintenance). Why are you doing it manually? The protobuf schema and introspection capabilities are strong enough to support completely automatic conversion while validating against the protobuf schema see a Python example here: translator: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=src/protobuf/examples/json.py;h=80c21ca23f8673afead2c0afc9870344ca8a1975;hb=0623bcc7d68029bea378045e57cdcf7dc5216f7f usage: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=src/protobuf/examples/encdec.py;h=4e947b67dd57501f4645c3cca7696281b61cc9f5;hb=0623bcc7d68029bea378045e57cdcf7dc5216f7f needs cleaning to run standalone, but you get the idea what I think the best route is to redo the above in C++, maybe starting with this https://github.com/renenglish/pb2json and doing the other direction based on the ideas above - Michael I was thinking about using protocol buffers to describe our model in terms of .proto files and then write a layer that automatically performs the serialization/deserialization to/from JSON according to our schemas. I started to look at protocol buffers recently so I might be asking something stupid. My question is: is protobuf the right choice to represent our data model when: 1. the model consists of hierarchy of classes. 2. a model instance is a tree (objects are connected creating a tree structure) 3. the model not static: these tree suffer changes (tree operations like add/delete/move/update nodes, etc.) Thanks in advance. -- 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. -- 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.
Re: [protobuf] proto to JSON/XML convertion library for C/C++
there's https://github.com/renenglish/pb2json which does protobuf-json but not vice versa there are several Python bidirection converters from which you can glean how to do the missing direction let me know when you're done ;) - Michael Am 10.04.2013 um 14:28 schrieb Giri Guntipalli: hi all, are there any libraries exists which can be used for generating JSON/XML serialization/deserialization to/from proto generated message classes. Giri. -- 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. -- 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.
Re: [protobuf] Running Google Protocol Buffers on a RTOS
Am 08.04.2013 um 08:37 schrieb Raghavendra Hegde: Hi, Thanks for the quick response. I have one question, to build nanopb protobuf-compiler, python-protobuf and libprotobuf-dev required. These utilities are not there in FreeRTOS environment. Could please provide info on this? no, but the nan...@groups.google.com group can, I dont think you will find much help on the issue here what you probably want is to install those tools on a linux host, generate the files there and compile for the target just like the rest of FreeRTOS I was not aware the 'FreeRTOS environment' is self-hosted so I dont think it is a question of installing these tools on FreeRTOS the only thing needed on the _target_ are the pb_encode.c and pb_decode.c files, but none of the tools but then this is a bit off-topic here - Michael -Raghu On Monday, 8 April 2013 12:03:57 UTC+5:30, Raghavendra Hegde wrote: Hi, Thanks for the quick response. I have one question, to build nanopb protobuf-compiler, python-protobuf and libprotobuf-dev. These utilities are not there in FreeRTOS environment. Could please provide info on this? -Raghu On Monday, 8 April 2013 10:48:22 UTC+5:30, Michael Haberler wrote: Am 08.04.2013 um 07:05 schrieb Raghavendra Hegde: Hi, It would be great, if you can provide the compilation procedure for FreeRTOS no I cant, because I dont have any FreeRTOS applications running here, but I dont see why nanopb would need anything more than a C compiler and maybe some of the documented options just pull nanopb, build it on linux, work through the examples and testcases and adapt one of those for FreeRTOS the code and documentation are very thorough, and the author - Petteri - is very responsive, so you wont have many problems I guess - Michael -Raghu On Friday, 5 April 2013 14:45:33 UTC+5:30, Michael Haberler wrote: Hi, I would suggest looking into nanopb: http://code.google.com/p/nanopb/ It has minimal platform dependencies and actually runs fine within the Linux kernel if needed - Michael Am Donnerstag, 4. April 2013 07:34:32 UTC+2 schrieb Raghavendra Hegde: Hi, I would like to build Google protocol buffer on FreeRTOS. Please let me know, is there any way to build GPB on RTOS. Regards, Raghavendra Hegde. -- 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 http://groups.google.com/group/protobuf?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- 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. -- 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.
Re: [protobuf] Running Google Protocol Buffers on a RTOS
Am 08.04.2013 um 07:05 schrieb Raghavendra Hegde: Hi, It would be great, if you can provide the compilation procedure for FreeRTOS no I cant, because I dont have any FreeRTOS applications running here, but I dont see why nanopb would need anything more than a C compiler and maybe some of the documented options just pull nanopb, build it on linux, work through the examples and testcases and adapt one of those for FreeRTOS the code and documentation are very thorough, and the author - Petteri - is very responsive, so you wont have many problems I guess - Michael -Raghu On Friday, 5 April 2013 14:45:33 UTC+5:30, Michael Haberler wrote: Hi, I would suggest looking into nanopb: http://code.google.com/p/nanopb/ It has minimal platform dependencies and actually runs fine within the Linux kernel if needed - Michael Am Donnerstag, 4. April 2013 07:34:32 UTC+2 schrieb Raghavendra Hegde: Hi, I would like to build Google protocol buffer on FreeRTOS. Please let me know, is there any way to build GPB on RTOS. Regards, Raghavendra Hegde. -- 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. -- 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.
[protobuf] Re: Running Google Protocol Buffers on a RTOS
Hi, I would suggest looking into nanopb: http://code.google.com/p/nanopb/ It has minimal platform dependencies and actually runs fine within the Linux kernel if needed - Michael Am Donnerstag, 4. April 2013 07:34:32 UTC+2 schrieb Raghavendra Hegde: Hi, I would like to build Google protocol buffer on FreeRTOS. Please let me know, is there any way to build GPB on RTOS. Regards, Raghavendra Hegde. -- 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.
Re: [protobuf] Running Google Protocol Buffers on a RTOS
Am 04.04.2013 um 07:34 schrieb Raghavendra Hegde: Hi, I would like to build Google protocol buffer on FreeRTOS. Please let me know, is there any way to build GPB on RTOS. I would suggest nanopb - http://koti.kapsi.fi/jpa/nanopb/ It has minimal platform requirements and even works in-kernel if that's whats needed - Michael Regards, Raghavendra Hegde. -- 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. -- 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.
