Nearly 5 years later, I found myself having the same problem.
Perfectly-valid serialized protobufs generated in C++ for message types
with no required fields suddenly started throwing
InvalidProtocolBufferException: Message was missing required fields.
exceptions in Java.
The problem is, as
don't see any references to library compatibility in the Java protobuf
page or the FAQ - apologies if this is covered somewhere...
https://developers.google.com/protocol-buffers/docs/javatutorial
https://developers.google.com/protocol-buffers/docs/faq
- Patrick
--
You received this message because
to write a library that uses proto-bufs
you can't inter-operate with other libraries that also use protobufs.
- Patrick
On Wed, Apr 16, 2014 at 3:24 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
While I don't speak for Google, I believe it's fairly well-established
that 2.4 and 2.5
Hey guys,
Will the next release officially support golang? And if so, is the
implementation / api based on goprotobuf? (We're looking for alternative
to replace goprotobuf ; we are currently considering
https://code.google.com/p/gogoprotobuf/.)
Thanks,
Patrick
--
You received this message
Hey guys,
I wrote two different patches which optimize python proto performance.
Both patches are running in production at Dropbox. What is the best way
to upstream these changes?
Patrick
Patch #1. Python message patch
(https://www.dropbox.com/s
require me to delve into descriptor databases and
pools? I'm using version 2.4.1 with the C++ backend for Python via
the PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp environment variable.
Thanks,
Patrick
--
You received this message because you are subscribed to the Google Groups
Protocol
it be that with sockets it fails and with
files it works fine?
Thanks again.
Patrick
On Apr 20, 6:17 pm, Jason Hsueh jas...@google.com wrote:
I suppose this should read POSIX file descriptors, which Windows supports. I
have never used protobuf on Windows personally, but the project is tested
appending, so with the current implementation, it is probably more
efficient to do the conversion after encoding.
If you have any questions or bugs about the library, feel free to send
me an email directly.
-Patrick
On Dec 30, 9:54 am, jd unicom...@gmail.com wrote:
Are there any plans for code
\reflection.py, line
1059, in _Des
erializeOneEntity
raise RuntimeError('TODO(robinson): Wiretype mismatches not
handled.')
RuntimeError: TODO(robinson): Wiretype mismatches not handled.
Thanks,
Patrick
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group
Background:
I've developed a C++ RPC server using protobufs as the IDL. It works
great. Thanks for protobufs!
Problem:
When a client connects to the RPC server, a seperate thread in the
server handles the connection and blocks, waiting for data from the
client.
My message parsing function for
, 2010, at 15:33 , Patrick wrote:
This is all fine and dandy except when I want to shutdown the server
or connection (not client initiated). The ReadTag (as well as the
other Read functions) blocks until data is received but I want it to
timeout after a specified amount of time. So in essence
, 2010, at 15:33 , Patrick wrote:
This is all fine and dandy except when I want to shutdown the server
or connection (not client initiated). The ReadTag (as well as the
other Read functions) blocks until data is received but I want it to
timeout after a specified amount of time. So
On Sep 28, 6:07 pm, Kenton Varda ken...@google.com wrote:
On Tue, Sep 28, 2010 at 5:38 PM, Evan Jones ev...@mit.edu wrote:
On Sep 28, 2010, at 18:36 , Patrick wrote:
I also have the problem that the RPC I wrote comes in a threaded model
and a multi-process model. The multi-process one
these two protos into python.
Thanks,
Patrick
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
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
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 schultz.patr...@gmail.com wrote:
When I construct a new
I meant CodedOutputStream of course.
On Feb 25, 9:18 pm, Patrick schultz.patr...@gmail.com 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
free to let me know if you have any suggestions or bugs, or you can
fork the project since it's developed in git.
-Patrick
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com
18 matches
Mail list logo
