Updates:
Status: WorkingAsIntended
Comment #1 on issue 274 by liuj...@google.com: Python generated protobufs
are not hashable in 2.4.0a
http://code.google.com/p/protobuf/issues/detail?id=274
Sorry we didn't mention this in document. Quote from our internal change
log:
Ok, I got it:
- the buffer at once is serializable
- a attribut of the buffer (a repeated string) might be not
so I have to copy the UnmodifiableLazyStringList to an ArrayList if
I'd like to use the attribut as an argument to pass between beans.
Pro: I dont need to include protobuf.jar into all
Can I specify that the message is abstract so I can implemented it at
will on my client?
This is possible in XSD schemas.
Lars
--
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
My problem is to serialize protobuf data in C++ and deserialize the
data in Java probably. In fact I get **InvalidProtobufferException**
in Java.
Here is my minimal example:
My protobuf file looks like this:
option java_outer_classname = NameProtos;
message Name {
required
On Fri, Apr 15, 2011 at 2:06 AM, platzhirsch
konrad.rei...@googlemail.comwrote:
My problem is to serialize protobuf data in C++ and deserialize the
data in Java probably. In fact I get **InvalidProtobufferException**
in Java.
Here is my minimal example:
My protobuf file looks like this:
Right! I think I refactored the whole writing and reading, still I am
stuck. However by this I get this Exception:
com.google.protobuf.UninitializedMessageException: Message missing
required fields: name
In C++:
Name name;
name.set_name(platzhirsch);
boost::asio::streambuf b;
std::ostream
On Fri, Apr 15, 2011 at 9:48 AM, platzhirsch
konrad.rei...@googlemail.comwrote:
Right! I think I refactored the whole writing and reading, still I am
stuck. However by this I get this Exception:
com.google.protobuf.UninitializedMessageException: Message missing
required fields: name
In C++:
I am sorry, could you clarify this? With destroy you mean call the
delete operator? The changes:
boost::asio::streambuf b;
std::ostream os(b);
ZeroCopyOutputStream *raw_output = new OstreamOutputStream(os);
CodedOutputStream *coded_output = new CodedOutputStream(raw_output);
Protobufs reflection support allows you to do this. We don't have a
walkthrough, but you can create types dynamically using the Descriptors
classes along with DynamicMessage. You can build the definitions you want
into a FileDescriptorProto (along with any dependencies it may have) and
call
yup, that's what I meant. Can you check that you are writing data to the
stream? Also, I didn't notice that you are writing the message length as a
header. Did you read that value from the socket prior to calling parse? The
Java-side parseFrom call should only be reading the data read by
Comment #2 on issue 274 by wbm...@gmail.com: Python generated protobufs are
not hashable in 2.4.0a
http://code.google.com/p/protobuf/issues/detail?id=274
Thanks for the clarification and the recommendation. I assumed there was a
good reason and it looks like now, even if I don't upgrade to
Adding the delete operator was good, now actually data it send, as the
socket.send function now returns a value 0.
I did not read the message length prior to calling parse, but I
changed it:
CodedInputStream cis =
Oh, maybe this line was flawed after all:
System.out.println(name.newBuilder().build().toString());
Which cannot work, can it? ;-)
I changed it to name.getName()
and there it is, the data I've sent, thank you!
--
You received this message because you are subscribed to the Google Groups
Oh, of course, glad it worked.
Also I realized I was mistaken about CodedOutputStream: it doesn't do any
internal buffering; it's OstreamOutputStream that does (some other
ZeroCopyOutputStream implementations do as well). In any event, keep
destroying the streams before you send.
On Fri, Apr 15,
We have bandied about the idea of supporting maps for some time. Past
discussion:
http://groups.google.com/group/protobuf/browse_thread/thread/5b43b26dec43bf99
At the moment, you just have to build your own map structures around the
protobuf.
On Fri, Apr 8, 2011 at 2:56 PM, Felix
The Descriptor classes don't support this as typically we want to enforce
that the Descriptor objects are in fact the same instances. In the protobuf
code you'll see simple pointer comparisons.
You could convert the descriptors back to DescriptorProtos and compare
those: however, this won't
Status: New
Owner: ken...@google.com
Labels: Type-Defect Priority-Medium
New issue 275 by zbe...@google.com: Incorrect installation with setup.py
breaks local override
http://code.google.com/p/protobuf/issues/detail?id=275
What steps will reproduce the problem?
1. Unpack the distribution
17 matches
Mail list logo
