Well, note that soon (hopefully in the next major release after 2.2.0 -- we
actually have someone actively working on it now) the Python implementation
will be able to wrap C++ classes for better performance. At that point it
will probably be easy to accomplish what you want by handing off most
, Kenton Varda ken...@google.com wrote:
Well, note that soon (hopefully in the next major release after 2.2.0 --
we
actually have someone actively working on it now) the Python
implementation
will be able to wrap C++ classes for better performance. At that point
it
will probably be easy
Frankly, negative numbers shouldn't be encoded as varints at all. It's only
for historical reasons that we do it.
If the last byte were 0x7f, that only gets you to 70 bits, so I'm not sure
how you could go from there to arbitrarily large numbers.
On Mon, Aug 10, 2009 at 10:05 AM, rog
We do not define any particular conventions for using protobufs over HTTP.
It's up to the app to decide what headers it needs and to publish those
requirements. I don't see any reason to treat a protocol buffer any
differently from any other sort of binary payload, though.
On Mon, Aug 10, 2009
Yes, MSVC projects are located in the vsprojects folder in the source code
distribution.
On Tue, Aug 11, 2009 at 9:50 AM, Shri snba...@gmail.com wrote:
Does protocol buffer support Visual studio 2008
Thanks
Shridhar
--~--~-~--~~~---~--~~
You received this
On Tue, Aug 11, 2009 at 9:36 AM, Peter Keen peter.k...@bugsplat.infowrote:
If I understand the docs correctly has_* will return false if the
value is the same as the default, which in the case of numbers
defaults to 0.
That is not correct. has_* returns true if the value was explicitly
http://code.google.com/p/protobuf/downloads/list
2009-08-11 version 2.2.0:
C++
* Lite mode: The optimize_for = LITE_RUNTIME option causes the compiler
to generate code which only depends libprotobuf-lite, which is much smaller
than libprotobuf but lacks descriptors, reflection, and
in
trying to Parse a message for themselves.
Jon
On Aug 11, 10:03 pm, Kenton Varda ken...@google.com wrote:
In your C++ code, are you storing the message as a NUL-terminated
string
(i.e. as char*)? Protocol Buffers are arbitrary byte arrays and may
contain
NULs, so this won't
On Tue, Aug 11, 2009 at 8:15 PM, Yingfeng yingfeng.zh...@gmail.com wrote:
Hi,
As is known to lots of people, std::string performs not good for such
reasons as copy-on-write,... etc.
Note that the C++ protobuf implementation generally assumes that string
copies are expensive and avoids them
Well there's good news and bad news. The bad news is that using protocol
buffers has been known to lead to large code footprints. The good news is
that it should be fairly easy to estimate how much it will bloat *your*
binary, without having to actually implement the whole system.
Protocol
chance? ;-)
On Aug 12, 10:56 pm, Kenton Varda ken...@google.com wrote:
Well there's good news and bad news. The bad news is that using protocol
buffers has been known to lead to large code footprints. The good news
is
that it should be fairly easy to estimate how much it will bloat *your
On Wed, Aug 12, 2009 at 3:27 PM, Noel Fegan nfe...@gmail.com wrote:
You don't happen to have a WSDL to proto file converter by any
chance? ;-)
No, but I bet you could write an XSLT to do it pretty easily.
On Aug 12, 10:56 pm, Kenton Varda ken...@google.com wrote:
Well there's good news
Please send a patch. Use diff -u to create it (see the man page), or if
you made your changes against the SVN sources, just use svn diff.
On Wed, Aug 12, 2009 at 10:08 PM, COFF a...@sibmail.ru wrote:
Hello Kenton!
I succesfully merge my project on new version of protobuf.
I made patches
Sorry, but mutually recursive messages must be declared in a single file.
It would be excessively complicated to support cyclically dependent files
under the current implementation.
On Thu, Aug 13, 2009 at 11:34 AM, Justin Muncaster
justin.muncas...@gmail.com wrote:
I have the following
Deciding exactly where to draw the line for lite mode was hard -- different
users want different things.
There's two reasonable options here:
1) Read the entire istream to a string first, then call ParseFromString.
Similarly, when writing, use SerializeToString() then write the entire
string to
on non const std::string)
On 14 авг, 02:24, Kenton Varda ken...@google.com wrote:
Please send a patch. Use diff -u to create it (see the man page), or
if
you made your changes against the SVN sources, just use svn diff.
On Wed, Aug 12, 2009 at 10:08 PM, COFF a...@sibmail.ru wrote
The encoding documentation:
http://code.google.com/apis/protocolbuffers/docs/encoding.html
http://code.google.com/apis/protocolbuffers/docs/encoding.htmlspecifies
that fixed-width numbers are encoded in little-endian order. However, you
only have to know that if you are writing a protobuf parser
agreement via the web page.
Let me know when you've signed and I'll submit this.
2009/8/13 COFF a...@sibmail.ru
New patch avoid this sent.
On 14 авг, 10:54, COFF a...@sibmail.ru wrote:
Thank you for answer. I will try doing this way too.
On 14 авг, 10:18, Kenton Varda ken...@google.com wrote
On Fri, Aug 14, 2009 at 1:18 PM, George Georgiev georgi.georg...@citrix.com
wrote:
1. How to serialize parts from the message without validation
Use the Partial serialization and parsing methods, e.g.
SerializePartialToString() and ParsePartialFromString(). These do not check
required
.
Thanks
-George
--
*From:* Kenton Varda [mailto:ken...@google.com]
*Sent:* Friday, August 14, 2009 2:01 PM
*To:* George Georgiev
*Cc:* Protocol Buffers
*Subject:* Re: combine protobuf messages
On Fri, Aug 14, 2009 at 1:18 PM, George Georgiev
georgi.georg
This is something I intended to do with descriptor sets but haven't had
time. Basically I think you should be able to specify descriptor set files
in the place of directories in the import path (with -I). You are the first
person to comment on it. :)
Implementing this will require some
Feel free to send me a patch updating the #ifdefs to properly handle
stlport. It looks like stlport follows the SGI interface for hash_map, so
just using the non-MSVC code path should do the trick. I think only hash.h
and maybe descriptor.cc would need to be updated.
On Sat, Aug 15, 2009 at
On Mon, Aug 17, 2009 at 10:21 AM, George Georgiev
georgi.georg...@citrix.com wrote:
Thanks,
Everything looks good now, except default values. I love the fact that if
the default value is explicitly stored in the message it override the base
value, and it doesn't if it is not. Am I right?
FWIW, one way to make your life a lot easier might be to statically link
against libprotobuf. That way you do not need to distribute anything, and
you do not need to distribute a new package when you update to a new version
of protocol buffers. This is the approach we take at Google -- we
I've actually worked on something like that recently, but tied to a
particular use case. I think you'll find it pretty hard to solve the
problem in a completely general-purpose way, unless you end up writing a
code generator of some sort. In order to hide the UIDs from the app, you
will need to
will get any
close to Java's total performance (serialization, deserialization and
object creation).
I was hoping to give our RMI environment a boost but I doesn't look
like this. I will give it another chance.
Tai
On 17 Aug., 22:07, Kenton Varda ken...@google.com wrote:
Oops, I missed
In theory it should work on any modern unix. In practice it's hard to say
what platforms may have quirks that cause problems. I test each release on
Linux, Visual Studio, Cygwin, MinGW, and Mac OSX, and Monty Taylor has been
testing on Solaris with Sun Studio. It probably works on other
The original value is being preserved. It's just being formatted
differently. The TextFormat parser knows that the field is a double even if
it sees only 10.
On Tue, Aug 18, 2009 at 3:11 PM, ajoy ajo...@gmail.com wrote:
Hi
I'm creating a Message in Java, with a double field in it . i set
The problem with these spec files is that they're large and complicated and
I just don't have time to learn how they work and maintain them. If someone
would like to commit to maintaining these things -- which means I'd call on
you to update them for each release, answer questions about them,
nanosecs
Average serialization time = 3609 6586 nanosecs
Average de-serialization time = 3533 9287 nanosecs
Based on that PB seems to be slower and I am not coming to the same
conclusion as stated in other performance tests?!
Tai
On Aug 17, 11:24 pm, Kenton Varda ken...@google.com wrote
I'd like to add this to the list, but I noticed that the wiki page is an
HTTPS link to a site with an invalid SSL certificate. I tried to change the
protocol to just HTTP but the site automatically redirects to HTTPS. Modern
browsers complain very loudly about this, and I feel weird posting a
On Wed, Aug 19, 2009 at 10:47 AM, Kevin Deldycke ke...@deldycke.com wrote:
BTW, should we continue packaging-related discussion of protobuf here ?
Please do.
Is this issue worth a bug report ?
Well, I haven't observed this problem on other platforms or distros. What
happens if you write
Makes sense. I'm happy to accept a patch along these lines.
On Tue, Aug 18, 2009 at 11:12 PM, Oliver Jowett oliver.jow...@gmail.comwrote:
While experimenting with LITE_RUNTIME I noticed that the C++ methods
DebugString() and ShortDebugString() are only present on Message, not
MessageLite.
Sigh. More bugs in descriptor bootstrapping, eh?
The problem is that without RTTI, MergeFrom(const Message other) cannot
tell if other is actually the exact same class as this, so it has to
fall back to reflection... but reflection does not work if descriptors
aren't available... and we're in
The source code generated by protoc is identical regardless of what platform
protoc itself is executed on. The runtime library is always required.
The Java code (and the Python code, and probably Perl too though that's a
third-party implementation) is completely platform-neutral so it should work
Nope, there hasn't been any off-list discussion.
Personally I have no opinion on the matter since it doesn't affect anything
that I do with protocol buffers. However, the Google Wave people -- who are
developing an open-source protocol that will use protocol buffers -- seem to
care about this and
On Tue, Aug 18, 2009 at 6:55 PM, Oliver Jowett oliver.jow...@gmail.comwrote:
Hi
Using 2.2.0, the compiler doesn't seem to be generating Java code for
the parseFrom(byte[],int,int) and
parseFrom(byte[],int,int,ExtensionRegistryLite) static methods.
Did it ever generate those methods? I
Cert Signing Authority) - it
certainly isn't in my trusted set of root certificates...
On Aug 19, 3:50 am, opticron nyphb...@gmail.com wrote:
It is a CACert certificate that is valid until May of 2010.
On Aug 18, 7:46 pm, Kenton Varda ken...@google.com wrote:
I'd like to add
that adding so many methods
is probably leading to binary bloat.
On Wed, Aug 19, 2009 at 5:18 PM, Oliver Jowett oliver.jow...@gmail.comwrote:
Kenton Varda wrote:
On Tue, Aug 18, 2009 at 6:55 PM, Oliver Jowett oliver.jow...@gmail.com
mailto:oliver.jow...@gmail.com wrote:
Hi
According to a google search for maven skip tests, you can skip them by
specifying -Dmaven.test.skip=true on the command line.
Of course, it would be nice to know why the tests are failing. Can you send
us the test result reports mentioned in the error log?
On Thu, Aug 20, 2009 at 7:19 AM,
know if this works?
On Fri, Aug 21, 2009 at 3:10 AM, Jesper Eskilson jes...@eskilson.se wrote:
On Fri, Aug 21, 2009 at 10:19 AM, Jesperjesper.eskil...@gmail.com wrote:
On Aug 20, 9:56 pm, Kenton Varda ken...@google.com wrote:
According to a google search for maven skip tests, you can skip
I'm pretty sure #1 is not protobuf's fault. I've never heard of libgcc_s
which means it's probably something GCC links against implicitly. And
anyway, if libwhatever.so.1 exists, there should always be a libwhatever.so
symlink to it... right?
Monty, can you comment on #2?
On Fri, Aug 21, 2009
Run configure --without-zlib to disable zlib support. Alternatively, fix it
and send me a patch. :)
On Fri, Aug 21, 2009 at 8:44 PM, Oliver Jowett oliver.jow...@gmail.comwrote:
Oliver Jowett wrote:
The tests start failing here:
[--] 14 tests from IoTest
[ RUN ]
message-DebugString() is a shortcut that returns a string representation of
the message.
On Fri, Aug 21, 2009 at 9:06 PM, Saptarshi saptarshi.g...@gmail.com wrote:
Hello,
I'm new to using Protocol Buffers and am debugging my program.
Is there a way to pretty print a Message? (I'm new to C++
Generally the most efficient way to serialize a message to stdout is:
message.SerializeToFileDescriptor(STDOUT_FILENO);
(If your system doesn't define STDOUT_FILENO, just use the number 1.)
If you normally use C++'s cout, you might want to write to that instead:
Yes, unlike C-style char*, C++'s std::string can store strings that contain
NUL bytes. You should never use .c_str() in this case -- use .data() and
.size() instead.
On Mon, Aug 24, 2009 at 12:58 PM, Saptarshi Guha
saptarshi.g...@gmail.comwrote:
Hello,
Thank you! Being new to c++ i had no
Maybe you should move your project to code.google.com? You wouldn't have to
host your SVN on (apparently) your own machine that way.
Anyway, I've added a link to your wiki page.
On Mon, Aug 24, 2009 at 8:09 PM, opticron nyphb...@gmail.com wrote:
Good news! It looks like I convinced the
You mean MutableExtension()? Yes, you can't use SetExtension() on
message-typed extensions because regular fields of message type don't have a
set_foo() accessor. So, you must use MutableExtension() instead.
On Tue, Aug 25, 2009 at 5:34 AM, Jesper Eskilson jes...@eskilson.se wrote:
On Tue,
In C++ all compiled-in extensions are automatically registered in a global
registry which is used automatically by all compiled-in classes. I now
regret this design decision due to a number of subtle problems it creates,
but for you it means that you don't have to do anything special.
On Wed,
Some linkers will drop object files that aren't referenced from anywhere, so
if your code doesn't actually use anything from the .proto file defining the
extension, it might not be linked in, and thus won't be in the registry.
This is one of the common problems that make me wish we had an
What version are you using? I thought 2.2.0 fixed this.
On Tue, Aug 25, 2009 at 7:37 AM, Srinivas G srinigu...@gmail.com wrote:
Currently Message::ParseFromBoundedZeroCopyStream() doesn't guarantee
that it will never attempt to read beyond the specified size.
I have seen cases where a
I'd recommend the array-of-pairs method because the parallel-arrays method
leaves you open to bugs where if the arrays aren't the same size and your
code doesn't carefully check for this, it could easily end up crashing due
to out-of-bounds accesses. This could be a security problem. Stick with
Yep, it's a very annoying problem. The solution I prefer is to add a dummy
usage of one of the classes in your .proto somewhere high-up in your
program, in a place that should logically know that the file is needed.
BTW, if you aren't actually explicitly using the extension anywhere, then
the
[+gak, who was working on a Maven plugin once upon a time]
On Thu, Aug 27, 2009 at 12:33 PM, rajesh poorv...@gmail.com wrote:
Hi All,
Right now I use the following command line command as
given in the documentation to create proto files . The command is :
protoc -I=$src
spend a lot of time in protobuf code.
On Thu, Aug 27, 2009 at 7:18 PM, Kenton Varda ken...@google.com wrote:
On Thu, Aug 27, 2009 at 2:06 PM, Saptarshi Guha
saptarshi.g...@gmail.comwrote:
Hello
I was thinking about this and had some questions
On Mon, Aug 24, 2009 at 3:29 PM, Kenton
Did you try what I suggested before -- serializing to a byte array instead,
and then writing that to the stream all at once?
It's possible that ObjectOutputStream itself is just really slow, but that
when using native Java serialization it uses special, highly-optimized code
paths.
On Thu, Aug
On Thu, Aug 27, 2009 at 2:06 PM, Saptarshi Guha saptarshi.g...@gmail.comwrote:
Hello
I was thinking about this and had some questions
On Mon, Aug 24, 2009 at 3:29 PM, Kenton Vardaken...@google.com wrote:
Generally the most efficient way to serialize a message to stdout is:
is doing some optimization?
On Aug 28, 4:05 am, Kenton Varda ken...@google.com wrote:
Did you try what I suggested before -- serializing to a byte array
instead,
and then writing that to the stream all at once?
It's possible that ObjectOutputStream itself is just really slow
://code.google.com/p/protobuf/source/browse/#svn/branches/maven-plugin
On Thu, Aug 27, 2009 at 9:06 PM, Kenton Varda ken...@google.com wrote:
[+gak, who was working on a Maven plugin once upon a time]
On Thu, Aug 27, 2009 at 12:33 PM, rajesh poorv...@gmail.com wrote:
Hi All
Ouch, this hole is probably a lot deeper than it looks.
First let me review some things which you may already know...
I assume these plugins are DLLs. Do you load and unload these plugins at
runtime, or just at startup? If you unload them at runtime, then each one
needs to be statically linked
/legal/corporate-cla-v1.0.html -- If your employer
does.
On Sat, Aug 22, 2009 at 6:46 PM, Oliver Jowett oliver.jow...@gmail.comwrote:
Kenton Varda wrote:
Run configure --without-zlib to disable zlib support. Alternatively,
fix it and send me a patch. :)
I took a look at fixing
Did you call ShutdownProtobufLibrary() before exiting the process?
On Fri, Aug 28, 2009 at 12:05 PM, bgg bru...@gmail.com wrote:
I'm using the C++ interface for protocol buffers. In my code I don't
declare any protocol buffers objects on the stack. I have pointers to
them declared. I have
Note that field number means the number you assign to the field in the
.proto file, whereas tag means the bytes that come before the field value
in the encoded message. You left-shift the field number to make the tag,
and right-shift the tag to get the field number.
On Fri, Aug 28, 2009 at 12:28
The problem is that the parameter binding that you are providing has type
DummyResponse* but the method you are trying to bind takes const
DummyResponse*. Even though the former is implicitly convertible to the
latter, the compiler will not consider this when selecting a template
overload. The
C++ Protocol Buffers use UTF-8 for all text encoding, regardless of
platform. If you want to use some other encoding in your code, you will
have to manually convert between that and UTF-8 when interacting with
Protocol Buffers.
In Java and Python everything is taken care of automatically, since
Thanks for fixing the docs, Henner.
On Sat, Aug 29, 2009 at 6:59 PM, Henner Zeller h.zel...@acm.org wrote:
And yeah, documentation needs to be fixed.
On Aug 28, 2009 1:35 PM, Omnifarious omnifari...@gmail.com wrote:
An example from
What compiler flags are you using? Since you were able to compile
libprotobuf itself, I assume you have turned on additional warnings for your
own project?
On Mon, Aug 31, 2009 at 3:26 PM, Joshua Haberman jhaber...@gmail.comwrote:
I just installed Snow Leopard, which ships with:
$ gcc
Use the --with-protoc option to configure to tell it to use a particular
protoc binary when building (rather than attempt to execute the one it just
built).
Other than that, cross-compiling works the same as with any
automake/autoconf package. E.g. I have cross-compiled Windows binaries on a
Mac
and the generated Makefile. Or will the --with-protoc
option
have this effect?
WBR
Günther
On 1 Sep., 18:25, Kenton Varda ken...@google.com wrote:
Use the --with-protoc option to configure to tell it to use a particular
protoc binary when building (rather than attempt to execute the one
You haven't mapped any directories into the import search path. Read the
docs for DiskSourceTree.
On Wed, Sep 2, 2009 at 11:00 AM, Vainstah h.a.s...@gmail.com wrote:
Hello Proto devs,
I am trying to load a protocol file and am using the Importer object
(from importer.h). I am using visual
On Sun, Sep 6, 2009 at 9:46 AM, Jesper Eskilson jes...@eskilson.se wrote:
On Thu, Sep 3, 2009 at 6:56 PM, Kenton Vardaken...@google.com wrote:
You want:
const UnknownFieldSet set =
cmd.GetReflection()-GetUnknownFields(cmd);
Ok, so if I have function which receives a message which as an
Sorry, it's actually SerializeWithCachedSizesToArray(). It's defined on the
MessageLite interface so every protocol message object has this method.
On Mon, Sep 7, 2009 at 7:03 AM, Dave W. evadef...@gmail.com wrote:
To allocate a correctly-sized array and
Since you haven't provided any code it's hard to speculate on what may be
going wrong.
On Wed, Sep 9, 2009 at 3:01 PM, rajesh poorv...@gmail.com wrote:
Hi All,
I ran some performance tests to compare the performance for
serializing-persisting-retrieving-desirializing of my POJOs and
clumsy
if I post the code here..lemme email it to you..can you please provide
me youremail address to which I can send the code to. I have a
'ken...@google.com' on your profile , do you want me to email it to
this id.
On Sep 9, 7:45 pm, Kenton Varda ken...@google.com wrote:
Since you haven't
On Thu, Sep 10, 2009 at 12:51 AM, SuKai sukai090...@gmail.com wrote:
In this page
http://code.google.com/intl/zh-CN/apis/protocolbuffers/docs/cpptutorial.html,
Parsing and Serialization section,
* |bool SerializeToString(string* output) const;|: serializes the
message and stores the
On Thu, Sep 10, 2009 at 4:36 PM, Henner Zeller h.zel...@acm.org wrote:
Hi,
On Thu, Sep 10, 2009 at 4:26 PM, George Georgiev
georgi.georg...@citrix.com wrote:
Sure, but it is really hard for me to prepare something general since the
java output files are located in a different folders based
Doesn't make any sense to me. Let me know if you find a solution.
On Mon, Sep 7, 2009 at 8:16 AM, Brice Figureau
brice...@daysofwonder.combrice%2...@daysofwonder.com
wrote:
Hmm, more information on the issue below:
On Mon, 2009-09-07 at 16:52 +0200, Brice Figureau wrote:
I'm using
On Thu, Sep 10, 2009 at 4:59 PM, George Georgiev georgi.georg...@citrix.com
wrote:
So you suggest if I change the java package in a proto file, I to update
the makefile too?
That seems reasonable to me. If you changed the package of any of your
other Java files it would mean moving source
On Fri, Sep 11, 2009 at 1:51 PM, Monty Taylor mord...@inaugust.com wrote:
Well, the build-if-newer is handled by either Make or VisualStudio, not
by the compiler in either case.
Right, the link is to a build system plugin. I'm all for build system
plugins for protocol buffers but those
Good call. I've committed this as rev 226. Thanks.
On Fri, Sep 11, 2009 at 7:21 AM, pierreK pierre.keste...@cea.fr wrote:
Hello,
[I'm using protobuf-2.2.0]
I would to suggest a minor modification to the file src/Makefile.am
Currently an out-of-source build works only for native build.
Hmm, now I'm confused. They imply that libprotobuf should be linked with
both -pthread *and* -lpthread, as the latter registers libpthread as some
sort of auto-loaded dependency, I guess. The internet does not provide very
much useful info on what the real best practice is.
On Wed, Sep 9, 2009
On Fri, Sep 11, 2009 at 3:25 PM, George Georgiev georgi.georg...@citrix.com
wrote:
How exactly this will handle the problem with the different output files?
It won't -- like I said, it's not what you were asking for.
We're still saying that your issue is the responsibility of the build
On Fri, Sep 11, 2009 at 4:22 PM, George Georgiev georgi.georg...@citrix.com
wrote:
I think that protoc already has a compromise with pure compiler
functionality - namely placing the java class in the package subfolder.
Since you have so strong fillings not to make another compromise you
On Sat, Sep 12, 2009 at 2:14 AM, Cyber Cobra bugspr...@gmail.com wrote:
Here's the info I'm looking for:
1. Is there a specification document more formal/detailed than
http://code.google.com/apis/protocolbuffers/docs/encoding.html ?
No. AFAIK there are no details missing from that
Hi Monty,
Can you test the attached patch and verify that it fixes the problem? (Kind
of hard to test here because we only have x86 machines which happily execute
unaligned reads.)
On Wed, Sep 9, 2009 at 12:18 AM, Monty Taylor mord...@inaugust.com wrote:
Hey guys,
I just filed an issue:
Committed as rev 228. Thanks.
On Mon, Sep 14, 2009 at 7:46 PM, Oliver Jowett oliver.jow...@gmail.comwrote:
Kenton Varda wrote:
Can you review the diff, too? At Google we have a policy of reviewing
all changes. Just tell me if it looks OK to you, or if there's anything
you'd recommend
Did your Absolutely! mean Absolutely, I'll test it! or Absolutely, it
worked!?
On Mon, Sep 14, 2009 at 4:35 PM, Monty Taylor mord...@inaugust.com wrote:
Kenton Varda wrote:
Hi Monty,
Can you test the attached patch and verify that it fixes the problem?
(Kind of hard to test here
advise.
Regards,
Hiram
On Sep 18, 12:34 pm, Kenton Varda ken...@google.com wrote:
So, his implementation is a little bit faster in two of the benchmarks,
and
impossibly faster in the other one. I don't really believe that it's
possible to improve parsing time by as much as he claims, except
as
possible.
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
On Sep 18, 6:43 pm, Kenton Varda ken...@google.com wrote:
Hmm, your bean and buffer classes sound conceptually equivalent to my
builder and message classes.
Regarding lazy parsing
implementation achieves
feature parity with mine. That way it's one less code base I need to
maintain! Best of luck and if you do change your mind and want to
poach any of the concepts or code, please feel free to do so.
Regards,
Hiram
On Sep 18, 9:40 pm, Kenton Varda ken...@google.com wrote:
I
Since protocol messages are value objects, it's generally not necessary to
mock them. The problem with interfaces is that they cannot make any
guarantee of immutability.
On Mon, Sep 21, 2009 at 3:24 AM, Brice Figureau
brice...@daysofwonder.combrice%2...@daysofwonder.com
wrote:
On Fri,
Hoffstaette
holger.hoffstae...@googlemail.com wrote:
If I may..
On Fri, 18 Sep 2009 23:16:03 -0700, Kenton Varda wrote:
Regarding maven plugins -- why can't the plugin just invoke protoc using
Runtime.exec()? What's the benefit of having the code generator running
inside the Maven
:
Kenton Varda wrote:
Does Python 3.x implement metaclasses the same way? It looks to me like
the metaclass may not be getting applied.
AIUI, setuptools (and therefore pkg_resources) have not yet been ported
to python3 yet. I believe there are discussions about including
pkg_resources
...@gmail.comwrote:
On Tue, Sep 22, 2009 at 5:57 AM, Kenton Varda ken...@google.com wrote:
So Java users don't like relying on C++ code in their build process. On
the other hand, most C++ users would not accept Java in their build process
either. But if we wrote the C++ code generator in C
If you invoke protoc like:
protoc --cpp_out=dllexport_decl=MY_EXPORT_MACRO:path/to/output/dir
myproto.proto
then it will generate code with MY_EXPORT_MACRO in all the right places.
However, this option is incomplete -- currently there is no way to force
the generated .pb.h to #include a header
The different accessor functions for C++ protobuf classes are documented in
detail here:
http://code.google.com/apis/protocolbuffers/docs/reference/cpp-generated.html
Message objects can be large, so you should avoid copying them if possible.
Instead, you should use the mutable_() accessor to
will be part of the next release.
On Wed, Sep 23, 2009 at 1:44 AM, Orbby Chang aql...@gmail.com wrote:
Just curious is the Python C/C++ implementation is on its way?
Kenton Varda
Wed, 03 Jun 2009 11:34:35 -0700
The plan is to modify the current Python implementation so that
message
objects can
On Thu, Sep 24, 2009 at 8:38 AM, am aamir...@gmail.com wrote:
Hello,
I am working with scalar values and fixed-length arrays. I need to
deserialize the entire message into a contiguous raw buffer in memory
such that all members of the data structure can be accessed by using
offsets against
I'm told that a new version of the JDK enforces some things more strictly
than slightly older versions did, which may be leading to these errors.
The solution presented to me was to cast the value returned by
internalGetResult()
to ExtendableMessage. Note that through generics, we *already know*
Maybe your system headers #define Free as a macro? Try adding #undef Free
before that line.
On Fri, Sep 25, 2009 at 7:25 AM, alex as.von.ch...@gmail.com wrote:
hi
when i #include google/protobuf/extension_set.h
the xlc++ always show an error message:
401 - 500 of 1054 matches
Mail list logo
