Glad that you found what works for you. What baffles me is why CopyFrom()
segfaults when given a DynamicMessage. DynamicMessage can't be cast to
Foo, but foo.CopyFrom() gets to be working with it. Did you find why it
segfaults?
On Friday, January 18, 2013 3:31:48 AM UTC+8, m wrote:
>
> Thanks
Sorry, there's a typo on that last line. It should be:
gpb::TextFormat::ParseFromString( "blah: \"some string\" bleh: 3", message
);
On Thursday, January 17, 2013 11:31:48 AM UTC-8, m wrote:
>
> Thanks for your reply.
>
> My application links against all the stub proto sources of the types I
Thanks for your reply.
My application links against all the stub proto sources of the types I will
be creating. What I've found works is if I use the default(?) descriptor
pool (google::protobuf::DescriptorPool::generated_pool()) and the default
message factory (google::protobuf::MessageFactor
Updates:
Cc: f...@google.com
Comment #1 on issue 454 by liuj...@google.com: Python API parallel read
access is not thread safe when repeated fields are empty
http://code.google.com/p/protobuf/issues/detail?id=454
Adding Frank to take a look.
--
You received this message because you a
Hi,
On 15.01.2013 17:32 schrieb Feng Xiao:
> On Tue, Jan 15, 2013 at 11:06 PM, Johannes Wienke <
> jwie...@techfak.uni-bielefeld.de> wrote:
>
>> Hi,
>>
>> On 01/15/2013 04:00 PM, Feng Xiao wrote:
>>> Protobuf messages are thread-compatible. You can read a protobuf message
>>> concurrently in mult
Status: New
Owner: liuj...@google.com
Labels: Type-Defect Priority-Medium
New issue 454 by johannes...@gmail.com: Python API parallel read access is
not thread safe when repeated fields are empty
http://code.google.com/p/protobuf/issues/detail?id=454
We have found out that the current impleme
