[protobuf] Re: Large message vs. a list message for smaller messages
@Evan - Right. So in that case, we would use the writeDelimitedTo or some such equivalent option to stream a number of small messages together. I got this far. My problem is trying to make this work with the Jersey REST framework. Here, for each type of input/output you send and receive, provider classes are created. So, the same is done for the protobuf type as well. These provider classes can receive only protobuf Message type objects which are then writtent to the output stream. The writeDelimitedTo method writes to stream. I cannot convert this stream to a message type without actually creating a separate proto file to handle this. Is there any way of working around this problem? On Jan 13, 5:57 am, Evan Jones ev...@mit.edu wrote: On Jan 12, 2011, at 8:38 , Meghana wrote: Would ListA also be considered a large message or will the encoding be done on each individual A message making it immune to the large message problem? ListA itself will be a large message if it contains a large message of a sub-messages. If you are really sending / writing a large number of messages, you want to read something like: http://code.google.com/apis/protocolbuffers/docs/techniques.html#stre... Good luck, Evan Jones -- Evan Joneshttp://evanjones.ca/ -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] strange problem while parsing an extension
Hi all,
I have a strange behavior with java release 2.3.0 and I need your help:
Protos.proto:
...
message Request {
required Api api_call = 1;
extensions 100 to 200;
}
message RefundRequest {
extend Request {
optional RefundRequest refund_request = 100;
}
required int32 orderId = 1;
}
...
Client (java):
Protos.RefundRequest refundRequest =
Protos.RefundRequest.newBuilder()
.setOrderId(2)
.build();
Protos.Request request =
Protos.Request.newBuilder()
.setApiCall(Protos.Api.REFUND)
.setExtension(Protos.RefundRequest.refundRequest,
refundRequest)
.build();
Server (java):
...
byte[] data; // data is properly initialized with all bytes transmitted
over the wire.
Protos.Request request = Protos.Request.parseFrom(data);
// request.getApiCall() is correct. now I need to get transmitted order
Id. I do expect to have 2.
ExtensionRegistry registry = ExtensionRegistry.newInstance();
registry.add(Protos.RefundRequest.refundRequest);
RefundRequest refundRequest = Protos.RefundRequest.parseFrom(
data, registry
);
...
here is the problem:
refundRequest.getOrderId() returns always 1 ?!? no exceptions during
encoding, transmitting and receiving the data.
What I do wrong?
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Issue 251 in protobuf: Suggestion for performance improvement with Python
Status: New Owner: ken...@google.com Labels: Type-Defect Priority-Medium New issue 251 by kleptog: Suggestion for performance improvement with Python http://code.google.com/p/protobuf/issues/detail?id=251 What steps will reproduce the problem? 1. Run the Python code What is the expected output? What do you see instead? About 10% of the runtime is spent in the methods DecodeVarint and ReadTag, each. With loop unrolling and some cleverness the runtime for these methods can be cut by 30%, leading to a 10% overall increase in performance. What version of the product are you using? On what operating system? protobuf-2.3.0 on a Debian Lenny amd64. Please provide any additional information below. I think that the performance improvement in the general case might be a bit less, since we use lots of repeated fields, which means these methods get called dozens of times per message. Using the attached file effected the speed increase for us. Note: I also played with moving these to external C modules but that did not help as much as I had hoped. The time for a 1-byte tag was about the same in C and in Python. The time for C was unaffected by the length of the tag but since single byte tags are by far the most common any performance increase was difficult to measure. Using PyPy does make a huge difference, which means that any use of external modules is counter productive in our case. I also briefly tried the extension code in 2.4.0 but that just threw an exception. Since it's marked as experimental I haven't filed a bug yet, but I can if it would help. Attachments: protobufopt.py 2.5 KB -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Issue 251 in protobuf: Suggestion for performance improvement with Python
Comment #1 on issue 251 by kleptog: Suggestion for performance improvement with Python http://code.google.com/p/protobuf/issues/detail?id=251 Note: I can imagine you want to ignore this issue as too ugly to live, but I figured at least posting it may help other people. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] strange behavior while parsing an extension
to make it simple, here is one proto file and two jUnits tests. The
first one passes through and the second one fails. See the comments for
details.
Protos.proto:
enum Api {
REFUND = 1;
}
message Request {
required Api api_call = 1;
extensions 100 to 200;
}
message RefundRequest {
required int32 orderId = 1;
}
extend Request {
optional RefundRequest refund_request = 100;
}
TestUnit1: (succeeds)
==
Protos.RefundRequest rr =
Protos.RefundRequest.newBuilder()
.setOrderId(3)
.build();
byte[] data = rr.toByteArray();
Protos.RefundRequest rr2 = Protos.RefundRequest.parseFrom(data);
// suceeds
Assert.isTrue( rr2.getOrderId() == 3 );
TestUnit2: (fails at the end)
==
Protos.RefundRequest rr =
Protos.RefundRequest.newBuilder()
.setOrderId(3)
.build();
Protos.Request request =
Protos.Request.newBuilder()
.setApiCall(Protos.Api.REFUND)
.setExtension(Protos.refundRequest, rr)
.build();
// returns true
Assert.isTrue( request.hasExtension(Protos.refundRequest) );
// returns true
Assert.isTrue( request.getExtension(Protos.refundRequest).equals(rr) );
byte[] data = request.toByteArray();
ExtensionRegistry registry = ExtensionRegistry.newInstance();
registry.add(Protos.refundRequest);
Protos.RefundRequest refundRequest = Protos.RefundRequest.parseFrom(
data, registry
);
// it fails and returns always 1
Assert.isTrue( refundRequest.getOrderId() == 3 );
What is wrong that the orderId is always returned as 1 and not 3 as it
is expected?
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: how to deal with the byte 0xFF in the business logic?
On Jan 13, 2:23 am, 飞 杨 youngphy.y...@dianping.com wrote: Dear sir, I found, in the protocolbuf int encode, the byte 0xFF may appear, then how can i distinguish the EOS and the business -1, the two both are -1 when use the inputstream.read().. Pay closer attention to the definition of InputStream.read(). The return type is an int, which is 32-bits. '-1' and 0x00FF are distinct values. Make the check before casting the return value to an byte. That being said, I wouldn't read data one byte at a time either without a good reason. Adam -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] compile protobuf with gcc2.96
Not able to do so. Any help? [root@localhost protobuf-2.3.0]# ./configure make make all-recursive make[1]: Entering directory `/build/installer/ext_src/protobuf-2.3.0' Making all in . make[2]: Entering directory `/build/installer/ext_src/protobuf-2.3.0' make[2]: Leaving directory `/build/installer/ext_src/protobuf-2.3.0' Making all in src make[2]: Entering directory `/build/installer/ext_src/protobuf-2.3.0/ src' /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. - I..-pthread -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -O2 -g -DNDEBUG -MT common.lo -MD -MP -MF .deps/common.Tpo -c - o common.lo `test -f 'google/protobuf/stubs/common.cc' || echo './'`google/protobuf/stubs/common.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -pthread -Wall -Wwrite- strings -Woverloaded-virtual -Wno-sign-compare -O2 -g -DNDEBUG -MT common.lo -MD -MP -MF .deps/common.Tpo -c google/protobuf/stubs/ common.cc -fPIC -DPIC -o .libs/common.o google/protobuf/stubs/common.cc: In function `void google::protobuf::ShutdownProtobufLibrary ()': google/protobuf/stubs/common.cc:356: no matching function for call to `vectorvoid (*) (), allocatorvoid (*) () ::at (int )' make[2]: *** [common.lo] Error 1 make[2]: Leaving directory `/build/installer/ext_src/protobuf-2.3.0/ src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/installer/ext_src/protobuf-2.3.0' make: *** [all] Error 2 -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] strange behavior while parsing an extension
You are parsing the serialization as a RefundRequest, not a Request. The 1
that is being returned is the value of the api_call field - on the wire this
looks like the order_id field - both have tag 1 and are varint encoded.
On Thu, Jan 13, 2011 at 8:58 AM, Simeon Mitev simeon.mi...@alegram.comwrote:
to make it simple, here is one proto file and two jUnits tests. The first
one passes through and the second one fails. See the comments for details.
Protos.proto:
enum Api {
REFUND = 1;
}
message Request {
required Api api_call = 1;
extensions 100 to 200;
}
message RefundRequest {
required int32 orderId = 1;
}
extend Request {
optional RefundRequest refund_request = 100;
}
TestUnit1: (succeeds)
==
Protos.RefundRequest rr =
Protos.RefundRequest.newBuilder()
.setOrderId(3)
.build();
byte[] data = rr.toByteArray();
Protos.RefundRequest rr2 = Protos.RefundRequest.parseFrom(data);
// suceeds
Assert.isTrue( rr2.getOrderId() == 3 );
TestUnit2: (fails at the end)
==
Protos.RefundRequest rr =
Protos.RefundRequest.newBuilder()
.setOrderId(3)
.build();
Protos.Request request =
Protos.Request.newBuilder()
.setApiCall(Protos.Api.REFUND)
.setExtension(Protos.refundRequest, rr)
.build();
// returns true
Assert.isTrue( request.hasExtension(Protos.refundRequest) );
// returns true
Assert.isTrue( request.getExtension(Protos.refundRequest).equals(rr) );
byte[] data = request.toByteArray();
ExtensionRegistry registry = ExtensionRegistry.newInstance();
registry.add(Protos.refundRequest);
Protos.RefundRequest refundRequest = Protos.RefundRequest.parseFrom(
data, registry
);
// it fails and returns always 1
Assert.isTrue( refundRequest.getOrderId() == 3 );
What is wrong that the orderId is always returned as 1 and not 3 as it is
expected?
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] strange problem while parsing an extension
See other thread
On Thu, Jan 13, 2011 at 3:37 AM, Simeon Mitev simeon.mi...@alegram.comwrote:
Hi all,
I have a strange behavior with java release 2.3.0 and I need your help:
Protos.proto:
...
message Request {
required Api api_call = 1;
extensions 100 to 200;
}
message RefundRequest {
extend Request {
optional RefundRequest refund_request = 100;
}
required int32 orderId = 1;
}
...
Client (java):
Protos.RefundRequest refundRequest =
Protos.RefundRequest.newBuilder()
.setOrderId(2)
.build();
Protos.Request request =
Protos.Request.newBuilder()
.setApiCall(Protos.Api.REFUND)
.setExtension(Protos.RefundRequest.refundRequest, refundRequest)
.build();
Server (java):
...
byte[] data; // data is properly initialized with all bytes transmitted
over the wire.
Protos.Request request = Protos.Request.parseFrom(data);
// request.getApiCall() is correct. now I need to get transmitted order Id.
I do expect to have 2.
ExtensionRegistry registry = ExtensionRegistry.newInstance();
registry.add(Protos.RefundRequest.refundRequest);
RefundRequest refundRequest = Protos.RefundRequest.parseFrom(
data, registry
);
...
here is the problem:
refundRequest.getOrderId() returns always 1 ?!? no exceptions during
encoding, transmitting and receiving the data.
What I do wrong?
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: how to deal with the byte 0xFF in the business logic?
As Adam said, -1 has a representation that is not just a single 0xFF. To decode a varint, you have to read the bytes until the most significant bit is 0. (See http://code.google.com/apis/protocolbuffers/docs/encoding.html#varints) Note that int32 values are sign-extended for wire compatibility with int64, so you will get a 10-byte varint. On Thu, Jan 13, 2011 at 3:49 AM, Adam Skutt ask...@gmail.com wrote: On Jan 13, 2:23 am, 飞 杨 youngphy.y...@dianping.com wrote: Dear sir, I found, in the protocolbuf int encode, the byte 0xFF may appear, then how can i distinguish the EOS and the business -1, the two both are -1 when use the inputstream.read().. Pay closer attention to the definition of InputStream.read(). The return type is an int, which is 32-bits. '-1' and 0x00FF are distinct values. Make the check before casting the return value to an byte. That being said, I wouldn't read data one byte at a time either without a good reason. Adam -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] compile protobuf with gcc2.96
This compiler is 10 years old, and apparently is not even an official release: http://gcc.gnu.org/gcc-2.96.html. You should upgrade to a newer version. On Thu, Jan 13, 2011 at 9:20 AM, Pinakin Mevawala pmevaw...@gmail.comwrote: Not able to do so. Any help? [root@localhost protobuf-2.3.0]# ./configure make make all-recursive make[1]: Entering directory `/build/installer/ext_src/protobuf-2.3.0' Making all in . make[2]: Entering directory `/build/installer/ext_src/protobuf-2.3.0' make[2]: Leaving directory `/build/installer/ext_src/protobuf-2.3.0' Making all in src make[2]: Entering directory `/build/installer/ext_src/protobuf-2.3.0/ src' /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. - I..-pthread -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -O2 -g -DNDEBUG -MT common.lo -MD -MP -MF .deps/common.Tpo -c - o common.lo `test -f 'google/protobuf/stubs/common.cc' || echo './'`google/protobuf/stubs/common.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -pthread -Wall -Wwrite- strings -Woverloaded-virtual -Wno-sign-compare -O2 -g -DNDEBUG -MT common.lo -MD -MP -MF .deps/common.Tpo -c google/protobuf/stubs/ common.cc -fPIC -DPIC -o .libs/common.o google/protobuf/stubs/common.cc: In function `void google::protobuf::ShutdownProtobufLibrary ()': google/protobuf/stubs/common.cc:356: no matching function for call to `vectorvoid (*) (), allocatorvoid (*) () ::at (int )' make[2]: *** [common.lo] Error 1 make[2]: Leaving directory `/build/installer/ext_src/protobuf-2.3.0/ src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/installer/ext_src/protobuf-2.3.0' make: *** [all] Error 2 -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Issue 152 in protobuf: Maven Protoc Plugin fails when a jar file contains a .proto file (FileNotFoundException)
Comment #6 on issue 152 by panwar007: Maven Protoc Plugin fails when a jar file contains a .proto file (FileNotFoundException) http://code.google.com/p/protobuf/issues/detail?id=152 Hello everyone, I am building my project on Windows and facing the same issue. I am not sure where to make the modification suggested by rktoo . Has this issue been resolved? -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Zig Zag Encoding
Hello, I am wondering why the integers are encoded as zig zags. It would seem much more intuitive to me to just truncate the number from the left. That is, store -1 as 0111, -2 as 0110, 1 as 0001, 2 as 0010 and so on. I am not proposing to change it. I am just curious about the design. Regards, David Srbecky -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: Large message vs. a list message for smaller messages
On Jan 13, 2011, at 4:38 , Meghana wrote: Is there any way of working around this problem? You can increase the limit with CodedInputStream.setSizeLimit, which is an easy route. The problem is that the performance is bad for really large messages, because the whole thing needs to be serialized/ deserialized to/from a single buffer. The high performance version would be to encode your own simple protocol. Something like: 1. Write the number of messages with writeRawVarint32 2. Write each message with writeDelimitedTo On the decoding side, do the opposite. I'm not familiar with the framework you are using, but this should be feasible. Hope this helps, Evan -- Evan Jones http://evanjones.ca/ -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Java Newbie Question: Attaching a CodedInputStream to an NIO Socket
On Jan 13, 2011, at 1:55 , Nader Salehi wrote: It does help. However, I seem to have some problem reading messages that way. My guess is that it has something to do with the fact that the channels are non-blocking. Is there any special thing to consider when working with such channels? You need to know the length of the message you are reading, then only call the parse method once you have the entire thing buffered. So you send the size first, then the message. On the receiving side, you read the size, then then you keep reading from the non-blocking socket until you have the whole thing buffered, then you parse it. I have code that actually does this that is open source, but it is research quality so it may not actually be helpful to others. But you may want to look at it: http://people.csail.mit.edu/evanj/hg/index.cgi/javatxn/file/260423aa1c25/src/ca/evanjones/protorpc/ProtoConnection.java#l40 Evan -- Evan Jones http://evanjones.ca/ -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Zig Zag Encoding
maybe I'm being slow (it is late here), but what would 126 look like?
You could say ah, pad to the expected length, but then -1 is encoded as
1110 - and as I see it, *that* is
what zip-zag attempts to avoid.
It also solves the problem of switching from 32 to 64 bit, as a zig-zag
number shouldn't change (IIRC).
Marc
On 13 January 2011 19:58, David Srbecky dsrbe...@gmail.com wrote:
Hello,
I am wondering why the integers are encoded as zig zags. It would
seem much more intuitive to me to just truncate the number from the
left. That is, store -1 as 0111, -2 as 0110, 1 as 0001, 2
as 0010 and so on.
I am not proposing to change it. I am just curious about the design.
Regards,
David Srbecky
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
Regards,
Marc
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Nested messages using C++
Hello,
I have nested messages like the following (it is a little more
complicated, but i am trying to simplify with this example).
package DB;
message Header
{
required int32 ID=1;
message param
{
required int32 size_m = 1;
required int32 size_n = 2;
}
required param p = 2;
}
message data
{
repeated double = 1;
}
message DB
{
required Header = 1;
required data = 2;
}
The problem I am having is that the accessor methods generated for the
DB does not have a
set_param( DB::Header::param ).
Is there something wrong with how I am structuring my messages? Any
help is appreciated.
Please let me know if this post is unclear and I will try and explain
myself better.
Thanks!
Linus
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Java sub-builders in 2.4.0
It seems that the sub-builders introduced for Java in 2.4.0 help to solve the issues in these two posts: Making 'Data' classes mutable: http://groups.google.com/group/protobuf/browse_thread/thread/1699791071e92c83/fad54dd509a649ea Builders containing builders: http://groups.google.com/group/protobuf/browse_thread/thread/8675678c4b973510/dd8f2134534630d9 I only wanted to express my appreciation for this change. It will help us a lot! Thanks guys! -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Nested messages using C++
I am new to PB and I just ran into this. Is it possible that the PB
compiler does not generate set_... methods for some nested messages?
Here is an example: I don't see set_... methods for ANY of the
parameters in the db message.
What am I missing???
package pd;
message nv
{
repeated int32 Length = 1;
}
message dp
{
required int32 DesignID = 1;
repeated double Design = 2;
}
message Shape
{
required int32 size_m = 1;
required int32 size_n = 2;
}
message ds
{
required int32 DesignID = 1;
repeated double data = 2;
}
message db
{
required nv numVars = 1;
repeated dp despar = 2;
required Shape db_size = 3;
repeated ds dtst = 4;
}
On Jan 13, 1:48 pm, Linus suram.su...@gmail.com wrote:
Hello,
I have nested messages like the following (it is a little more
complicated, but i am trying to simplify with this example).
package DB;
message Header
{
required int32 ID=1;
message param
{
required int32 size_m = 1;
required int32 size_n = 2;
}
required param p = 2;
}
message data
{
repeated double = 1;
}
message DB
{
required Header = 1;
required data = 2;
}
The problem I am having is that the accessor methods generated for the
DB does not have a
set_param( DB::Header::param ).
Is there something wrong with how I am structuring my messages? Any
help is appreciated.
Please let me know if this post is unclear and I will try and explain
myself better.
Thanks!
Linus
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: Nested messages using C++
On Thu, Jan 13, 2011 at 5:38 PM, Linus suram.su...@gmail.com wrote:
I am new to PB and I just ran into this. Is it possible that the PB
compiler does not generate set_... methods for some nested messages?
Here is an example: I don't see set_... methods for ANY of the
parameters in the db message.
For message type fields, there is no set_... method. The codegen produces
mutable_... methods instead. Otherwise it is easy to write inefficient
code - set would require a potentially expensive copy of the message.
What am I missing???
package pd;
message nv
{
repeated int32 Length = 1;
}
message dp
{
required int32 DesignID = 1;
repeated double Design = 2;
}
message Shape
{
required int32 size_m = 1;
required int32 size_n = 2;
}
message ds
{
required int32 DesignID = 1;
repeated double data = 2;
}
message db
{
required nv numVars = 1;
repeated dp despar = 2;
required Shape db_size = 3;
repeated ds dtst = 4;
}
On Jan 13, 1:48 pm, Linus suram.su...@gmail.com wrote:
Hello,
I have nested messages like the following (it is a little more
complicated, but i am trying to simplify with this example).
package DB;
message Header
{
required int32 ID=1;
message param
{
required int32 size_m = 1;
required int32 size_n = 2;
}
required param p = 2;
}
message data
{
repeated double = 1;
}
message DB
{
required Header = 1;
required data = 2;
}
The problem I am having is that the accessor methods generated for the
DB does not have a
set_param( DB::Header::param ).
Is there something wrong with how I am structuring my messages? Any
help is appreciated.
Please let me know if this post is unclear and I will try and explain
myself better.
Thanks!
Linus
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: Nested messages using C++
By the way this is documented here:
http://code.google.com/apis/protocolbuffers/docs/reference/cpp-generated.html#fields
On Thu, Jan 13, 2011 at 5:42 PM, Jason Hsueh jas...@google.com wrote:
On Thu, Jan 13, 2011 at 5:38 PM, Linus suram.su...@gmail.com wrote:
I am new to PB and I just ran into this. Is it possible that the PB
compiler does not generate set_... methods for some nested messages?
Here is an example: I don't see set_... methods for ANY of the
parameters in the db message.
For message type fields, there is no set_... method. The codegen produces
mutable_... methods instead. Otherwise it is easy to write inefficient
code - set would require a potentially expensive copy of the message.
What am I missing???
package pd;
message nv
{
repeated int32 Length = 1;
}
message dp
{
required int32 DesignID = 1;
repeated double Design = 2;
}
message Shape
{
required int32 size_m = 1;
required int32 size_n = 2;
}
message ds
{
required int32 DesignID = 1;
repeated double data = 2;
}
message db
{
required nv numVars = 1;
repeated dp despar = 2;
required Shape db_size = 3;
repeated ds dtst = 4;
}
On Jan 13, 1:48 pm, Linus suram.su...@gmail.com wrote:
Hello,
I have nested messages like the following (it is a little more
complicated, but i am trying to simplify with this example).
package DB;
message Header
{
required int32 ID=1;
message param
{
required int32 size_m = 1;
required int32 size_n = 2;
}
required param p = 2;
}
message data
{
repeated double = 1;
}
message DB
{
required Header = 1;
required data = 2;
}
The problem I am having is that the accessor methods generated for the
DB does not have a
set_param( DB::Header::param ).
Is there something wrong with how I am structuring my messages? Any
help is appreciated.
Please let me know if this post is unclear and I will try and explain
myself better.
Thanks!
Linus
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Nested messages using C++
Cool!
Thank you for the clarification.
On Jan 13, 5:44 pm, Jason Hsueh jas...@google.com wrote:
By the way this is documented
here:http://code.google.com/apis/protocolbuffers/docs/reference/cpp-genera...
On Thu, Jan 13, 2011 at 5:42 PM, Jason Hsueh jas...@google.com wrote:
On Thu, Jan 13, 2011 at 5:38 PM, Linus suram.su...@gmail.com wrote:
I am new to PB and I just ran into this. Is it possible that the PB
compiler does not generate set_... methods for some nested messages?
Here is an example: I don't see set_... methods for ANY of the
parameters in the db message.
For message type fields, there is no set_... method. The codegen produces
mutable_... methods instead. Otherwise it is easy to write inefficient
code - set would require a potentially expensive copy of the message.
What am I missing???
package pd;
message nv
{
repeated int32 Length = 1;
}
message dp
{
required int32 DesignID = 1;
repeated double Design = 2;
}
message Shape
{
required int32 size_m = 1;
required int32 size_n = 2;
}
message ds
{
required int32 DesignID = 1;
repeated double data = 2;
}
message db
{
required nv numVars = 1;
repeated dp despar = 2;
required Shape db_size = 3;
repeated ds dtst = 4;
}
On Jan 13, 1:48 pm, Linus suram.su...@gmail.com wrote:
Hello,
I have nested messages like the following (it is a little more
complicated, but i am trying to simplify with this example).
package DB;
message Header
{
required int32 ID=1;
message param
{
required int32 size_m = 1;
required int32 size_n = 2;
}
required param p = 2;
}
message data
{
repeated double = 1;
}
message DB
{
required Header = 1;
required data = 2;
}
The problem I am having is that the accessor methods generated for the
DB does not have a
set_param( DB::Header::param ).
Is there something wrong with how I am structuring my messages? Any
help is appreciated.
Please let me know if this post is unclear and I will try and explain
myself better.
Thanks!
Linus
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
