I'm using protoc as the raw .proto parser for protobuf-net (I then
process the compiled binary for code-generation); at the moment, it is
very sensitive about line endings - if it isn't LF, it won't work.
This creates a bit of a nag for Windows users, as you have to go out
of your way to get the
Which class in the ProtoBuf Java api would be used to encode to a binary
stream?
Is there a short example or tutorial on how to encode (using Java) to a
binary stream for RCP?
a short code snippet on how to encode/decode would be super helpful.
thanks
jrv
You have to flush the CodedOutputStream.
You should just do this instead:
byte[] data = person.build().toByteArray();
On Thu, Jul 2, 2009 at 12:44 AM, J.V. jvsr...@gmail.com wrote:
I'm trying to get the following to work but nothing is being written to
the output stream.
any ideas?
Just call writeTo():
void writeToStream(Message message, OutputStream out) {
message.writeTo(out);
}
On Thu, Jul 2, 2009 at 7:47 AM, J.V. jvsr...@gmail.com wrote:
Which class in the ProtoBuf Java api would be used to encode to a binary
stream?
Is there a short example or tutorial on how
Thanks, for some reason I'm' getting the same error. If you have an
example of encoding to a stream and then decoding, it would be greatly
appreciated.
I will get it fully working and update the tutorial or post it somewhere
if desired.
thanks
jrv
Kenton Varda wrote:
You have to flush the
Protoc treats \r as plain whitespace, so it should have no problem with
Windows line endings. I just tested this and sure enough, protoc works fine
with .proto files that use Windows-style line endings.
Mac pre-OSX line endings (\r with no \n) won't work if the file contains any
comments.
What
Write to a stream:
message.writeTo(stream);
Parse from a stream:
message = MyType.parseFrom(stream);
If you need to read/write multiple messages on the same stream (or the
stream does not end immediately after the first message), use
writeDelimitedTo() and parseDelimitedFrom().
On Thu, Jul
protoc actually expects its input to be UTF-8 (though non-ASCII characters
are only allowed in default values for string fields). It just doesn't like
the BOM.
On Thu, Jul 2, 2009 at 12:44 PM, Marc Gravell marc.grav...@gmail.comwrote:
My bad... it isn't the line endings - it is the UTF8 BOM;
OK... is there any way it /could/ silently ignore the BOM? ;-p
I can try to advise the caller to use files without BOMs, but protoc
reads UTF8 anyway it seems reasonable to accept a BOM?
Marc
--~--~-~--~~~---~--~~
You received this message because you are
If you want to write up a patch to recognize a UTF8 BOM and ignore it, go
ahead. You can just modify the Tokenizer class to recognize and discard a
BOM appearing at the beginning of the input.
On Thu, Jul 2, 2009 at 1:31 PM, Marc Gravell marc.grav...@gmail.com wrote:
OK... is there any way it
I notice the replacement ThirdPartyAddOns page; can you please also
include protobuf-net in the RPC section? It provides 2 separate RPC
implementations (WCF-based and bespoke).
Also; I wonder if it might help to clarify (at the top) which
languages are provided in the official codebase; then the
Done and done.
I didn't know protobuf-net had RPC or I would have listed it on the RPC
implementations page some time ago.
On Thu, Jul 2, 2009 at 1:47 PM, Marc Gravell marc.grav...@gmail.com wrote:
I notice the replacement ThirdPartyAddOns page; can you please also
include protobuf-net in the
What's the difference between all these links?
On Thu, Jul 2, 2009 at 4:08 PM, Chris Kuklewicz turingt...@gmail.comwrote:
Kenton,
Could you change the link on the
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns
page for Haskell from
Hello protobuf gurus-
I'm just getting started with the python version of protobuf, using
v2.10. I want to store some lists of floats in a database's blob
field. When using a nested Message structure with the packed=true
option, I'm getting errors that look like this:
Traceback (most recent call
I'm on windows, using Visual Studio 2008 SP1, compiling a Release x64
build of libprotobuf. The lib file is 29,570KB big, is that
expected?
I'm using the provided visual studio projects, but I added the x64
configuration to them, perhaps I have some options set incorrectly or
something.
(The
Yeah, I think it's broken.
In reflection.py there is a line:
return decoder.Position() - content_start
I think (untested) that it should actually be:
return decoder.Position() - initial_position
I have no idea how this got past testing and I have asked the people
responsible to fix it.
On Thu, Jul 2, 2009 at 5:33 PM, Alex Black a...@alexblack.ca wrote:
I'm on windows, using Visual Studio 2008 SP1, compiling a Release x64
build of libprotobuf. The lib file is 29,570KB big, is that
expected?
I was going to say no way, but sure enough, the 32-bit release build is
18,154k, so
You'd have to ask the AppEngine people. Someone from that team submitted
the input_stream.py change.
The problem is that both protocol buffers and AppEngine place themselves in
the google package. Protocol Buffers has, from day one, declared the
package as a namespace package using setuptools,
OK, I'll ask over there. thanks
On Jul 2, 6:55 pm, Kenton Varda ken...@google.com wrote:
You'd have to ask the AppEngine people. Someone from that team submitted
the input_stream.py change.
The problem is that both protocol buffers and AppEngine place themselves in
the google package.
Thanks Kenton, thats reassuring.
From: Kenton Varda [mailto:ken...@google.com]
Sent: Thursday, July 02, 2009 8:56 PM
To: Alex Black
Cc: Protocol Buffers
Subject: Re: libprotobuf.lib, 29mb?
On Thu, Jul 2, 2009 at 5:33 PM, Alex Black a...@alexblack.ca wrote:
20 matches
Mail list logo
