@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
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
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
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
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;
}
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
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
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
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
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
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]#
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
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
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
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
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
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
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:
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
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
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
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,
22 matches
Mail list logo