On Thu, Jul 31, 2014 at 10:33 AM, Gustavo Temple
wrote:
>
> Has anyone considered the porting Protobuf to the PPC64 architecture?
>
>
It should already work without any changes.
-gps
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsu
l/corporate-cla-v1.0.html -- If your employer
does.
> On Monday, March 14, 2011 2:45:26 AM UTC-3, Gregory P. Smith wrote:
>>
>> On Tue, Mar 8, 2011 at 9:05 AM, maxw wrote:
>>
>>> As far as I can tell, the python protocol buffer code is not yet
>>> compatib
On Tue, Mar 8, 2011 at 9:05 AM, maxw wrote:
> As far as I can tell, the python protocol buffer code is not yet
> compatible with python 3.x. I found a few messages in this discussion
> forum indicating that some people had worked on this, but I saw no
> pointer to actual code. Are you aware of
On Sat, Jan 8, 2011 at 10:05 AM, Atamurad Hezretkuliyev
wrote:
>
> Following Evan's advice, I've run experiment using the repository version.
> According to my test, Google's C++ parser code is 7.6 times faster than pure
> python, which is consistent with Yang's results.
>
> Our C decoder is twice
err, please ignore this section of my message:
On Mon, Jan 19, 2009 at 5:04 AM, Gregory P. Smith wrote:
>
> Please submit patches for enhancements in the issue tracker. For some
> reason its not accepting bugs.
>
> BTW, for further potential optimization try a less linea
>
> FWIW, I played around with various other versions of this function, using a
> comparison tree similar to the C++ code and such but nothing beat your
> simpled unrolled loop in python 2.x. Calling dis.dis() on each function to
> see the python byte code disassembly is revealing.
>
> side note:
In general I'm a fan of submitting patches via the issue/bug tracker. I'm
not sure what Kenton prefers.
Regardless, sign a contributor license agreement as mentioned here:
http://groups.google.com/group/protobuf/msg/3b72718909d26b0a
Your patch looks good but there is one improvement to make:
Do
int vs long is a python 2.x annoyance. It goes away in 3.x as the int
vs long distinction disappears.
Regardless, the correct thing to do in 2.x is to accept both int and
long types, this unit test is being too strict. What matters is the
actual value, not the exact type. In decoder_test.py
Re
