Status: New
Owner: ken...@google.com
Labels: Type-Defect Priority-Medium
New issue 168 by kaushik.ramajayam: Class
com.google.protobuf.CodedInputStream has no method named isAtEnd()
http://code.google.com/p/protobuf/issues/detail?id=168
What steps will reproduce the problem?
1. Write a functi
Comment #1 on issue 168 by kaushik.ramajayam: Class
com.google.protobuf.CodedInputStream has no method named isAtEnd()
http://code.google.com/p/protobuf/issues/detail?id=168
Oops, my bad... I was using the wrong jar file (ver. 2.0.3). This isn't a
bug.
--
You received this message because
The purpose on RpcChannel is to implement physical wire data transfer
for your service. If you use one of existing implementations of
transport you, probably, don't care, but I'm implementing my own
transport using asynchronous AMQP protocol. And channel encapsulates
sender and listener functionali
Comment #21 on issue 66 by alexei.dvoretskii: cannot install using
easy_install
http://code.google.com/p/protobuf/issues/detail?id=66
Our python2.6 installation on windows lives in W:\Python\Python26 and I was
able to
install the egg into
W:\Python\Python26\Lib\site-packages\protobuf-2.3.
I am a new protocol buffers and python. I have a bytes field that
repeats. What is the proper syntax for the add then filling the
bytes.
message AlertToDevicesMessage {
required string alert = 1;
repeated bytes device_tokens = 2;
}
a2 = xxx.AlertToDevicesMessage()
a2.alert = "bl
Bytes are represented using the str type. So you do:
a2.device_tokens.add("a byte string")
On Thu, Feb 25, 2010 at 9:09 AM, Garry wrote:
> I am a new protocol buffers and python. I have a bytes field that
> repeats. What is the proper syntax for the add then filling the
> bytes.
>
> messag
Actually, it's append(), not add():
a2.device_tokens.append("a byte string")
On Thu, Feb 25, 2010 at 1:55 PM, Kenton Varda wrote:
> Bytes are represented using the str type. So you do:
>
> a2.device_tokens.add("a byte string")
>
> On Thu, Feb 25, 2010 at 9:09 AM, Garry wrote:
>
>> I am a
Updates:
Status: WorkingAsIntended
Comment #2 on issue 168 by ken...@google.com: Class
com.google.protobuf.CodedInputStream has no method named isAtEnd()
http://code.google.com/p/protobuf/issues/detail?id=168
(No comment was entered for this change.)
--
You received this message beca
When I construct a new CodedInputStream:
this->fd = sock.impl()->sockfd();
ZeroCopyInputStream *raw_input = new FileInputStream(this->fd);
this->input = new CodedInputStream(raw_input);
It hangs in the constructor. I ran a backtrace and can see that it is
hanging in the Re
Weird, read() on a socket should return as soon as *any* data is available,
not wait until the entire buffer can be filled. Have you set some unusual
flags on your socket which may be causing it to behave this way?
On Thu, Feb 25, 2010 at 5:20 PM, Patrick wrote:
> When I construct a new CodedIn
I have investigated further and saw that the buffer wasn't being
flushed; I should of realized this earlier.
Any reason why the Java CodedInputStream has a flush method but the c+
+ API has no equivalent?
On Feb 25, 9:04 pm, Kenton Varda wrote:
> Weird, read() on a socket should return as soon as
I meant CodedOutputStream of course.
On Feb 25, 9:18 pm, Patrick wrote:
> I have investigated further and saw that the buffer wasn't being
> flushed; I should of realized this earlier.
> Any reason why the Java CodedInputStream has a flush method but the c+
> + API has no equivalent?
>
> On Feb 2
In C++ the destructor flushes the stream. Java does not have destructors,
so an explicit flush was necessary.
Note that allocating and destroying CodedStreams on the stack is very cheap.
These objects are not designed to be long-lived. So, it's generally not
necessary to flush one -- just let t
13 matches
Mail list logo