Updates:
Status: Accepted
Owner: ken...@google.com
Comment #2 on issue 248 by ken...@google.com: protobuf will not compile
without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
Hmm. I don't think we should automatically fall back to thread-hostile
co
On Wed, Dec 1, 2010 at 3:33 AM, Evan Jones wrote:
> The instanceof approach to switch between the two is a good idea. When I
> wrote my implementation, I was concerned about the thread-safeness issues,
> although I don't think I ever considered this particular version. However, I
> think this can
Cool. Serialization and parsing themselves should actually be improved even
more than that, but having other Python code around it waters down the
numbers. :) Also, note that if you explicitly compile C++ versions of your
messages and link them into the process, they'll be even faster. (If you
Hi Siju,
This is pretty cool. I added it to the third-party add-ons wiki.
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns
Just a minor complaint: You are not Google, so your code should not live
under the com.google package. Can you please move it to a different
package? Perhaps com
There's a (slightly outdated) list of contributors here:
http://code.google.com/p/protobuf/source/browse/trunk/CONTRIBUTORS.txt
But I think it's probably best to list Google as the author. I did not
invent protocol buffers; I just wrote version 2 and open sourced it, and I
had help.
I don't re
Updates:
Status: Accepted
Labels: -FixedIn-2.4.0
Comment #3 on issue 196 by ken...@google.com: Python: Ascii output is not
assured to be in utf-8
http://code.google.com/p/protobuf/issues/detail?id=196
Jisi, I'm not convinced that this is fixed. The as_utf parameter simply
p
Evan is correct. The best way to write code which deals with a generic
protobuf type is to have it take a default instance as a parameter. From
that you can do everything else.
This is actually better than passing around Class objects, because it allows
users to use DynamicMessages with your cod
The file you attached is not useful without source code.
But what would be even better is if you could provide the stack trace for
the NullPointerException. The parser should never throw NPE and I'm not
aware of any bugs which cause it to throw NPE.
BTW, it's very easy for bytes which are not ac
I assume this is happening at startup? Is it possible that you are somehow
linking two copies of the same .pb.cc into your binary? There are cases
where the linker doesn't catch this, especially when dynamic linking is
involved, but sometimes even with static linking. Speaking of which, are
you
Comment #2 on issue 247 by ken...@google.com: Ability to redirect file
output to stdout
http://code.google.com/p/protobuf/issues/detail?id=247
What happens if multiple files are generated? For example, if you
have "option java_multiple_files = true;" in your .proto file. This seems
like
Updates:
Status: Fixed
Labels: FixedIn-2.4.0
Comment by liuj...@google.com:
Fixed in r358
Affected issues:
issue 223: Python Package Doesn't Contain Compiler Plugin Module
http://code.google.com/p/protobuf/issues/detail?id=223
issue 224: Protobuf installation error in Cy
Updates:
Status: New
Comment #2 on issue 179 by ken...@google.com: Visual C++ error C1091 when
compiling protoc generated code with over 64k descriptor
http://code.google.com/p/protobuf/issues/detail?id=179
This proves complicated to fix, because we have lots of code that passes
aro
On Tue, Dec 7, 2010 at 7:08 PM, Kenton Varda wrote:
> Cool. Serialization and parsing themselves should actually be improved even
> more than that, but having other Python code around it waters down the
> numbers. :)
The times are from a minimal microbenchmark using Python's timeit module:
nru
Updates:
Cc: liuj...@google.com
Comment #13 on issue 210 by liuj...@google.com: Java code should detect
incompatible runtime library version
http://code.google.com/p/protobuf/issues/detail?id=210
Hmm, not very clear about the maven version compatibility... So suppose you
have a pom.
On Tue, Dec 7, 2010 at 9:19 PM, Yang Zhang wrote:
> > Also, note that if you explicitly compile C++ versions of your
> > messages and link them into the process, they'll be even faster. (If you
> > don't, the library falls back to DynamicMessage which is not as fast as
> > generated code.)
>
> I
Comment #14 on issue 210 by aantono: Java code should detect incompatible
runtime library version
http://code.google.com/p/protobuf/issues/detail?id=210
It would if you specify, what Maven calls, a range -> [1.0,2.0), which
would basically read that anything inclusive between 1.0 and 2.0, b
On Tue, Dec 7, 2010 at 9:40 PM, Kenton Varda wrote:
> On Tue, Dec 7, 2010 at 9:19 PM, Yang Zhang wrote:
>>
>> > Also, note that if you explicitly compile C++ versions of your
>> > messages and link them into the process, they'll be even faster. (If
>> > you
>> > don't, the library falls back to
17 matches
Mail list logo