Thanks for doing this! Can you send it to me as a code review via
codereview.appspot.com? Also, you'll need to sign the CLA if you haven't
already:
http://code.google.com/legal/individual-cla-v1.0.html -- If you own
copyright on your work.
http://code.google.com/legal/corporate-cla-v1.0.html --
The descriptor itself contains a list of all of the defined fields for the
type. E.g.:
const Descriptor* type = message-GetDescriptor();
for (int i = 0; i type-field_count(); i++) {
const FieldDescriptor* field = type-field(i);
// handle field
}
On Tue, Apr 14, 2009 at 6:09 PM,
of an explicit initialization as a long term solution
where
all ordering issues are controlled. Your thoughts on this?
To me it sounds like a lot of work without very much benefit.
On Tue, Apr 14, 2009 at 10:29 AM, Kenton Varda ken...@google.com wrote:
I think you could just do something
We will absolutely maintain backwards-compatability of the wire format in
future versions. A version of protocol buffers that wasn't backwards
compatible would be thoroughly useless.
However, our idea of compatibility means that newer versions of the code
can successfully parse messages produced
.
As for the explicit initialization I humbly disagree but I understand
your point completely. Maybe someday there will be another
initialization issue that isn't as easily solved and it can be revisited.
-- Wink
On Wed, Apr 15, 2009 at 12:25 PM, Kenton Varda ken...@google.com wrote:
On Tue, Apr
Petar, can you review this?
Christian: Thanks, I don't think we had any idea this was happening (doh).
Can you sign the CLA if you haven't already?
http://code.google.com/legal/individual-cla-v1.0.html -- If you own the
copyright on your patch.
On Mon, Apr 20, 2009 at 8:51 PM, Wink Saville w...@google.com wrote:
I assume the wire format for all variations of protobuf
are compatible of course there are no guarantees.
Yes, they are definitely compatible.
In my little test program I'm using both and see that
they are generating
The protocol buffers implementation was designed to run on beefy server
machines where we regularly run binaries with hundreds of megs of code and
don't worry about it that much.
Optimizing for code size does make the code a lot slower, true, but this is
compared to an insanely fast base. It's
There is no central repository of descriptors in Java. It wouldn't really
work because Java normally does not load classes until they are first used,
so the descriptors wouldn't appear in the repository until you manually
loaded the classes somehow.
Instead, you should just create a MapString,
This is suggested from time to time. The problem is that validating
messages is an arbitrarily complex operation, and the only complete
solution to this problem would involve defining an entire turing-complete
functional programming language which you could use to specify validation
constraints.
SerializeTo*() only aborts if required fields are missing. You can protect
yourself against this problem in any of the following ways:
* Compile your release builds with NDEBUG defined. The check will then be
skipped in release builds, and the message will be written even if some
required fields
It appears as if your make is not properly expanding the $^ variable -- it's
replacing it with the empty string. Try using gmake?
On Thu, Apr 23, 2009 at 8:22 AM, tim.es...@gmail.com wrote:
Hi,
I am trying to build protobuf 2.0.3 on FreeBSD 7.1 and am running into
an error in the make
You're specifically talking about the Java implementation. We quite
intentionally chose to make message objects completely immutable. Version 1
of protocol buffers (never released publicly) used mutable objects, and we
found it lead to many bugs as people would modify messages that were
environments. Do you know how big the performance penalty
is for using array-based InputStream in protobuf context?
Thanks,
Yegor
On Apr 24, 9:01 pm, Kenton Varda ken...@google.com wrote:
Hi all,
I just updated SVN (rev 120) with a large bundle of changes recently made
to
our internal copy
On Mon, Apr 27, 2009 at 8:38 PM, Dan danle...@gmail.com wrote:
Hello,
I've recently started using Google Protocol Buffers with Python on my
server. I'm writing code to convert my data source into a binary
payload, but I'm running into some snags and was wondering if there
was a better way
that on my first
readthrough and was using MergeFrom, which I would guess is a tad
slower.)
-Daniel
On Tue, Apr 28, 2009 at 12:58 AM, Kenton Varda ken...@google.com wrote:
On Mon, Apr 27, 2009 at 8:38 PM, Dan danle...@gmail.com wrote:
Hello,
I've recently started using Google
On Wed, Apr 29, 2009 at 1:14 PM, burtonator burtona...@gmail.com wrote:
I have a few thoughts after looking at the generated Java source.
No particular order...
- why does the class have to be final? I can see one wanting to have
business logic (or data type manipulation logic) that
The incoming request has to somehow specify what method it is trying to
call. Then you can do:
const MethodDescriptor* method =
service-GetDescriptor()-FindMethodByName(method_name);
if (method == NULL) {
// no such method
} else {
Message* request =
Are you, like Fedor, linking to the CRT statically (/MT)? If so, does
linking dynamically (/MD) change anything? I wonder if this leads to a
condition where CRT functionality is being used before it has been
initialized -- because initialization order between the CRT and libprotobuf
would not be
this
week.
On Mon, May 4, 2009 at 9:45 AM, Peter K. koots...@gmail.com wrote:
Hi Kenton,
Thanks for the quick response.
On May 4, 12:07 pm, Kenton Varda ken...@google.com wrote:
Are you, like Fedor, linking to the CRT statically (/MT)? If so, does
linking dynamically (/MD) change anything
On Mon, May 4, 2009 at 11:12 AM, Peter K. koots...@gmail.com wrote:
OK, there seems to be projects called gtest and gtest_main that
are in the solution file, but don't seem to be in the repo.
Oh yeah, you're expected to run autogen.sh to get that, but I guess that's
hard on Windows unless you
, point is you don't need cygwin unless you want to build the protobuf
tests from SVN.
On Mon, May 4, 2009 at 5:46 PM, Peter K. koots...@gmail.com wrote:
On May 4, 7:57 pm, Kenton Varda ken...@google.com wrote:
On Mon, May 4, 2009 at 11:12 AM, Peter K. koots...@gmail.com wrote:
OK, there seems
On Tue, May 5, 2009 at 8:15 PM, Hong Zhang h...@google.com wrote:
Hi, Kenton,
I am not familiar with protobuf compiler, so my comment may be off.
Since existing code does something like this.
static class Foo {
Foo() { ... }
} foo;
Actually, a lot of code doesn't look like that
Added to http://code.google.com/p/protobuf/wiki/RPCImplementations
On Tue, May 5, 2009 at 10:26 PM, Jun Tsai jun.t...@gmail.com wrote:
Protocol Buffers RPC Server Implemention based on Mina(2.0-M5) and
Protobuf(2.0.3).
I had implemented a protocol buffers rpc server.
Thanks, committed as revision 138.
On Wed, May 6, 2009 at 12:26 PM, jas...@google.com wrote:
Looks good!
On 2009/05/06 19:05:36, kenton wrote:
Addressed comments (see below) and synced, new patch set uploaded.
http://codereview.appspot.com/53053/diff/1/5
File
Write the field like this:
optional .foo.Foo foo = 1;
The leading period tells the compiler that foo refers to the foo at the
global scope (i.e. the package), not the foo in the current scope (the
field). (It's the same semantics and C++ namespaces.)
This is also fixed in version 2.1.0 --
to be flipped from multi-threaded to multi-threaded DLL,
otherwise the linker gets upset. I forgot to do this after my last update
of the gtest code.
On Wed, May 6, 2009 at 2:34 PM, Kenton Varda ken...@google.com wrote:
Hi all,
I've uploaded release candidate 2.1.0rc1 here:
http
On Fri, May 8, 2009 at 7:08 AM, Peter K. koots...@gmail.com wrote:
1. MS Dev Studio 2008 converts the project on opening the solution
file.
Yep, that's expected -- we distribute MSVC 2005 project files (and gtest's
are MSVC 2003).
2. cl : Command line warning D9035 : option 'Wp64' has
What does your protoc command-line look like? Does your project contain
multiple .proto files that import each other? If so you need to make sure
to pass the same -I (or --proto_path) flag to each one.
On Fri, May 8, 2009 at 5:47 AM, Peter K. koots...@gmail.com wrote:
Hi All,
OK, so we've
On Fri, May 8, 2009 at 9:03 AM, Henner Zeller h.zel...@acm.org wrote:
fixed32 or fixed64 would be probably better. uint32 is encoded in
variable length which would make bitfields typically larger than
necessary.
Depends. If you are only using the first few (low-order) bits, then uint32
is
at 6:41 PM, Peter K. koots...@gmail.com wrote:
On May 8, 5:04 pm, Kenton Varda ken...@google.com wrote:
What does your protoc command-line look like? Does your project contain
multiple .proto files that import each other? If so you need to make
sure
to pass the same -I (or --proto_path
On Fri, May 8, 2009 at 9:49 PM, clinton.fos...@quest.com wrote:
It was necessary to add a length prefix to the request/response
messages in order to remove the dependency on closing the connection
to know when the protobuf was finished being read. Also, since
Message.Builder.mergeFrom()
What do you mean? It seems to me that they should be written the same way
you'd write any other unit test in Python.
On Mon, May 11, 2009 at 3:51 AM, ssmai...@gmail.com wrote:
Hi,
Can anyone tell me how to proceed with writing Python Unit test cases
for Protocol Buffers. It would be great
serialisation to a
stream then?
Thanks again for the help.
Dan
On May 12, 5:26 pm, Kenton Varda ken...@google.com wrote:
Protocol Buffers has a bytes type. That's what it's talking about.
Just
change string to bytes in your .proto file. (They work exactly the
same
in C
In v2.1.0 I've added a parameter to the configure script --with-protoc=
which lets you specify an alternate protoc binary to use when compiling.
This way, the makefiles won't invoke the protoc they just built. So,
cross-compiling should work.
However, I haven't actually tested this with
On Tue, May 12, 2009 at 12:28 PM, Marc Gravell marc.grav...@gmail.comwrote:
What implementation are you using? Given that most of the
implementations use code-generation (rather than reflection), I'm
wondering if this is protobuf-net?
(since that supports inheritance by representing it as
Yes, use descriptors and the reflection interface. What language are you
using?
On Tue, May 12, 2009 at 1:31 PM, ajoy ajo...@gmail.com wrote:
I'm trying to write a recursive function that goes thru all fields of
a message. Without hardcoding anything, is there a way to retrieve all
repeated
On Tue, May 12, 2009 at 2:34 PM, ajoy ajo...@gmail.com wrote:
Thanks!
I'm using C++
got around mainly with the help of reflection-FieldSize(*message,
field) and reflection-GetRepeatedMessage(*message, field, j);
That's the way to do it.
On May 12, 2:27 pm, Kenton Varda ken
http://code.google.com/p/protobuf/downloads/list
Aaaand, I just realized that CHANGES.txt still has the release date as .
:(
/me is not very good at release engineering.
Oh well.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
Here's the major changes (from CHANGES.txt):
General
* Repeated fields of primitive types (types other that string, group, and
nested messages) may now use the option [packed = true] to get a more
efficient encoding. In the new encoding, the entire list is written
as a single byte
Updated documentation covering all this has been submitted and should go
live in a couple hours.
http://code.google.com/apis/protocolbuffers/docs/overview.html
On Wed, May 13, 2009 at 4:06 PM, Kenton Varda ken...@google.com wrote:
Here's the major changes (from CHANGES.txt):
General
Yes, linking against pthreads is required. Technically it always was, but
on certain platforms (e.g. Linux), it just happened that the set of pthread
functions used by libprotobuf were all implemented in libc itself, so if you
forgot to use -lpthead it worked anyway.
I suppose that should be in
FYI: This is fixed in the 2.1.0 release (you can call
google::protobuf::ShutdownProtobufLibrary() to clean up all leaks).
On Fri, Mar 27, 2009 at 7:07 PM, Kenton Varda ken...@google.com wrote:
On Fri, Mar 27, 2009 at 4:30 PM, Oleg Smolsky o...@smolsky.net wrote:
So, the next question
On Thu, May 14, 2009 at 4:08 PM, reid.mad...@tektronix.com wrote:
There's only one problem with this. It assumes that you have a locally
compiled and installed the protoc compiler. Thus, before building a
cross-compiled version, one must also build a native version. This is an
unnecessary
On Fri, May 15, 2009 at 5:06 PM, reid.mad...@tektronix.com wrote:
Kenton,
The flaw in your assumption is that I actually use the current machine to
build my product. I don't.
I'm cross-compiling on platform A (redhat) for deployment on platform B
(mips). Other than the
On Sun, May 17, 2009 at 6:57 AM, Chris Kuklewicz turingt...@gmail.comwrote:
I am patching the Haskell implementation and I have a follow up
question to this:
On May 14, 12:06 am, Kenton Varda ken...@google.com wrote:
* The type name resolver will no longer resolve type names to fields
I cannot reproduce this problem in MSVC 2008.
Are you using precompiled headers? Could it relate to that?
What happens if you replace using namespace std; with a bunch of usign
std::Foo; lines covering everything used by libprotobuf?
On Mon, May 18, 2009 at 11:34 AM, Zachary Turner
Any comment, Petar?
On Fri, May 15, 2009 at 7:21 AM, Nicholas Reid njr...@gmail.com wrote:
Hi Petar Kenton,
Have there been any recent developments on the Python C
implementation? I'd be more than happy to run a prototype through its
paces for testing purposes and provide feedback - it
If your compiler transforms string literals to a non-ASCII character set,
then the code generated by the protocol compiler won't work. We could
perhaps fix this by escaping every character in the embedded descriptor, but
other problems might come up. I don't have enough experience with EBCDIC to
You sent me a personal e-mail to which I replied. My reply was that I
unfortunately don't have time to review any large amount of code, but I'm
happy to put this on the list anyway if you'd like.
On Mon, May 18, 2009 at 7:36 PM, xiliu.t...@gmail.com
xiliu.t...@gmail.comwrote:
Any update on
The code does not compile in VS2k8.
Did you try replacing the using namespace std; with a bunch of individual
using std::Foo; directives? Can we work around the problem that way?
On Mon, May 18, 2009 at 11:56 AM, Zachary Turner divisorthe...@gmail.comwrote:
I managed to get it down to a
On Wed, May 20, 2009 at 12:35 AM, cosmin.cremare...@gmail.com wrote:
./google/protobuf/stubs/once.h, line 114: Warning (Anachronism):
Formal argument 2 of type extern C void(*)() in call to pthread_once
(_once*, extern C void(*)()) is being passed void(*)().
This warning seems to be saying
at Google.
IMO, you should provide a --cross-compile option so the build knows when to
not run tests… Or, better yet, use the auto-tools to detect
cross-compilation environments and auto-disable testing…
Reid
*From:* Kenton Varda [mailto:ken...@google.com]
*Sent:* Friday, May 15, 2009 9
On Wed, May 20, 2009 at 10:44 AM, Monty Taylor mo...@inaugust.com wrote:
Kenton Varda wrote:
On Wed, May 20, 2009 at 12:35 AM, cosmin.cremare...@gmail.com
mailto:cosmin.cremare...@gmail.com wrote:
./google/protobuf/stubs/once.h, line 114: Warning (Anachronism):
Formal
You can capture log output using SetLogHandler():
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.common.html#SetLogHandler.details
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.common.html#SetLogHandler.detailsHowever,
you have a
You need to link against libprotobuf by adding -lprotobuf to your linker
command-line.
On Mon, May 25, 2009 at 7:46 AM, jacobsmbox-goog...@yahoo.de wrote:
Hi,
After successfully compiling my lib using a generated protocol buffer
class, i am receiving this awful error when i try to load it:
On cygwin you should really use the provided configure script and
makefiles. Once you've installed the library you can use your IDE for your
own project that uses protocol buffers.
If you really want to compile with an IDE, then you will at least have to
run the configure script to produce
, 2009 at 1:08 AM, jacobsmbox-goog...@yahoo.de wrote:
Thanks a lot!
It worked well after i figured how to add it to the configure script
of my PHP extension project:
./configure ... EXTRA_LDFLAGS='-lprotobuf'
On 25 Mai, 21:50, Kenton Varda ken...@google.com wrote:
You need to link against
On Thu, May 28, 2009 at 12:17 PM, Marc Gravell marc.grav...@gmail.comwrote:
A couple of questions on the new packed encoding;
1: do the core implementations complain if the body length is given as
zero? i.e. no items? I don't expect they would *write* this, but would
they be happy to *read*
) ? std::cout well done ;) \n : std::cout T_T
have to change your design\n;
}
This current design kind of satisfying me, i will try to test it in
the Java generated Classes :) .
cheers,
Pascal Ly.
On May 28, 8:44 pm, Kenton Varda ken...@google.com wrote:
You can only have mutually
directory `/cygdrive/d/JavaFT/protobuf-2.1.0rc1'
make: *** [all] Error 2
On Mon, May 25, 2009 at 2:57 PM, Kenton Varda ken...@google.com wrote:
On cygwin you should really use the provided configure script and
makefiles. Once you've installed the library you can use your IDE for
your
own
The official implementations do NOT accept multiple encodings, but it would
theoretically be possible for them to do so. This wasn't implemented mainly
because code size bloat is a big problem and accepting multiple encodings
would increase code size -- even users who don't even use [packed=true]
Yep, you've found one of many ways that you can make protoc generate code
that does not compile. Unfortunately it would be extremely difficult and
tedious for us to fix every possible instance of this -- most of the
problems are things no one has even thought of yet -- so we try to focus
only on
I don't know much about protobuf-c specifically, but my guess is that it's
saying that it saw a tag with fixed64/sfixed64/double type that did not have
8 bytes after it -- i.e. the input was cut off in the middle of the value.
Probably what is happening is your message is being cut short in
Sorry, I don't understand your question. Can you write out the hypothetical
.proto file that defines these types, and example code showing what you
imagine the solution looking like?
On Mon, Jun 1, 2009 at 3:44 PM, ajoy ajo...@gmail.com wrote:
Hi,
If I have a chain of enclosed messages,
till I see 'e'. At that point I
can concatenate all field names in the stack and get A.B.C.D.e as the fully
qualified name of 'e'.
Is there an easier way?
thanks
-Ajoy
On Mon, Jun 1, 2009 at 6:22 PM, Kenton Varda ken...@google.com wrote:
Sorry, I don't understand your question. Can you
Yeah, we've dropped the ball on this. Unfortunately the people in charge of
the Python protocol buffers implementation also have other, apparently very
demanding projects, and thus Python protobuf hasn't gotten the attention it
deserves. Sadly even Google doesn't have infinite engineering
There is not a built-in way to do this. I recommend creating a registry
object -- similar to ExtensionRegistry -- in which you can register all the
types you need to handle. Then you can register the types in high-level
code and pass that down to the RPC system, which itself then won't need to
Done. I both added VB to the list of acronyms and added a separate copy
of the link under Visual Basic to make sure it's visible.
On Wed, Jun 3, 2009 at 3:36 AM, Marc Gravell marc.grav...@gmail.com wrote:
protobuf-net now with added Visual Basic ;-p
Please could you update the
Look at TextFormat (part of the C++, Java, and Python official
implementatinos) for an example of how descriptors and reflection can be
used to encode/decode messages in an alternative format. The TextFormat
class works with any message type, even ones not yet invented -- this is
when descriptors
OK, I'm confused. The packed encoding is already supported for repeated
integers, floats, etc. Can you clarify some more?
On Wed, Jun 3, 2009 at 12:18 PM, Marc Gravell marc.grav...@gmail.comwrote:
I'm sorry - I didn't do a good job with the question...
I meant with things like integer,
Thanks for the patch!
It looks like you were using the examples as a test. Running make check
in the top directory will run a much better suite of tests -- do they pass?
Assuming it does work, can you re-send that patch as an attachment (it looks
like it has been mangled), or even send it to me
On Thu, Jun 4, 2009 at 5:23 AM, Stas Oskin stas.os...@gmail.com wrote:
Thanks for the tip, any idea if the plain UNIX pipes are working with
protobuf?
You can send a protocol buffer over a pipe, sure. It's just bytes.
Regards.
2009/5/25 Christopher Smith cbsm...@gmail.com
When you compile your app, are you making sure to use the same C runtime
library against which you compiled libprotobuf? It looks like it's
complaining about missing functions in the C runtime.
On Thu, Jun 4, 2009 at 8:58 AM, wayne.mene...@gmail.com wrote:
Hi,
I am trying to use Google
Yes, you need to use the protobuf runtime library. Each language has an
independent runtime library. libprotobuf.so is only for C++. For Java,
there is a Maven-built jar file on which you need to depend. You don't need
to link against the C++ dynamic library for Java apps.
On Thu, Jun 4, 2009
:50 PM, Kenton Varda ken...@google.com wrote:
When you compile your app, are you making sure to use the same C runtime
library against which you compiled libprotobuf? It looks like it's
complaining about missing functions in the C runtime.
On Thu, Jun 4, 2009 at 8:58 AM, wayne.mene
. I didnt find any other places where the older references were
being used.
I think you need to update your source to handle this issue.
Thanks,
Wayne
On Thu, Jun 4, 2009 at 7:12 PM, Kenton Varda ken...@google.com wrote:
/MDd is the debug library. libprotobuf.lib only links against
:
I was using newer run time libraries than VS2003 to build my application,
whilst using VS2003 to build the libraries. Sorry about the confusion.
-Wayne
On Fri, Jun 5, 2009 at 5:03 PM, Kenton Varda ken...@google.com wrote:
You said you were using VS2003. According to your link
It looks like it's having trouble finding stuff from the C++ standard
runtime. Did you make sure to link against the same version of the runtime?
On Sat, Jun 6, 2009 at 6:58 AM, k.muraha...@gmail.com wrote:
Hi all,
I have followed the steps suggested in readme.txt in vsprojects folder
of
I haven't seen that before. Can you set a breakpoint in malloc_error_break
like the error suggests and get a stack trace?
On Sun, Jun 7, 2009 at 4:23 AM, kgs kgo...@gmail.com wrote:
Hi,
I encountered a strange problem using protocol buffers on Mac OSX
(Leopard).
My configuration is:
-
0x4cba in main ()
(gdb) c
Continuing.
123
Bob
b...@example.com
Program exited normally.
===
Thanks for feedback!
Cheers,
Kamil
On 8 Cze, 18:19, Kenton Varda ken...@google.com wrote:
I haven't seen that before. Can you set a breakpoint in
malloc_error_break
like the error suggests
On Mon, Jun 8, 2009 at 12:57 PM, kgs kgo...@gmail.com wrote:
Any ideas?
Nope. :(
Let me know if you figure it out.
Kamil
On 8 Cze, 21:43, Kenton Varda ken...@google.com wrote:
Strange. It looks like it's inside the STL string implementation that
something is going wrong. Do you
I still think that this doesn't belong in the scope of protocol buffers, but
rather some higher-level utility library.
That said, what does your proposal offer over the
writeDelimited/parseDelimited methods added to the Java runtime in 2.1.0?
(Still need to add them to C++ and Python...)
On Tue,
On Tue, Jun 9, 2009 at 12:11 AM, Jon Skeet sk...@pobox.com wrote:
On Jun 9, 1:42 am, Kenton Varda ken...@google.com wrote:
In the next version there will be a third option: LITE_RUNTIME. This
variant is like optimizing for speed but will generate code that only
depends on a lighter
Ah, I see. How about if we just extend parseDelimited() to return null at
EOF?
On Tue, Jun 9, 2009 at 12:36 PM, Jon Skeet sk...@pobox.com wrote:
On Jun 9, 8:28 pm, Kenton Varda ken...@google.com wrote:
I still think that this doesn't belong in the scope of protocol buffers,
but
rather
Yep, sorry for changing it out from under you, but the old design was
possibly the dumbest thing I did when developing proto2. :/
On Thu, Jun 11, 2009 at 7:49 PM, daveb lahike...@gmail.com wrote:
well, my diagnosis on the test code situation was largely wrong. i
still think there is a
http://code.google.com/apis/protocolbuffers/docs/techniques.html#streaming
On Sun, Jun 14, 2009 at 4:14 PM, Alex Black a...@alexblack.ca wrote:
Is there a way to start sending a message before its fully composed?
Say we have messages like this:
message Entity
{
required int32 id = 1;
This is tricky as the Python API (like the C++ API) has a strong sense of
ownership. Outer messages own the message objects embedded inside them.
In the Python API, this is necessary because assigning a field in an
optional sub-message may also cause the sub-message itself to become present
in
The Java implementation does not contain any mutable singletons, so as long
as you are accessing different objects, there is no need to worry about
thread-safety. So, yes, multiple threads may call parseFrom() at the same
time as long as they are parsing from different streams.
On Mon, Jun 15,
Everything you say sounds right. If you want to know precisely what these
methods do, or how much overhead they incur, I encourage you to look at the
code in repeated_field.h -- it's not very complicated.
However, instead of trying to control all this in detail, it's usually
easiest to simply
On Tue, Jun 16, 2009 at 10:13 AM, RobertFach
robert.f...@inf.tu-dresden.dewrote:
So if I understood you right, say my example message test contains 10
chunks, if I clear that message and parse another message containing 9
chunks, no allocation would be performed and 1 cleared chunk object
Mostly looks fine.
Note that a varint can be up to 5 bytes. You should probably just use
CodedOutputStream::Varint32Size() to compute the exact size so that you can
allocate a buffer that is exactly large enough.
Also note that if your message is large (say, 10k or more), allocating a
single
.
- Alex
--
*From:* Kenton Varda [mailto:ken...@google.com]
*Sent:* Wednesday, June 17, 2009 4:42 PM
*To:* Alex Black
*Cc:* Christopher Smith; Protocol Buffers
*Subject:* Re: 'Streaming' messages (say over a socket)
Mostly looks fine.
Note that a varint
Note that the protocol buffer parser is not asynchronous. That means you
either need to feed it an entire message at once, or it will need to block
waiting for mode data to arrive on the input stream. So if you want to do
something asynchronous, you best bet is probably to do your own buffering
On Thu, Jun 18, 2009 at 8:47 PM, Kenton Varda ken...@google.com wrote:
Note that the protocol buffer parser is not asynchronous. That means you
either need to feed it an entire message at once, or it will need to block
waiting for mode data to arrive on
s/mode/more
the input stream. So
for repeated_field.h.
message Foo {
optional sequence int32 sequence_of_int32 = 1;
}
On Wed, Jun 17, 2009 at 4:34 PM, Kenton Varda ken...@google.com wrote:
Can you please send me example code which crashes when given invalid
input, and/or provide a stack trace for the crash
, ditto for responses.
Regards,
Brodie
On Jun 19, 12:47 pm, Kenton Varda ken...@google.com wrote:
On Thu, Jun 18, 2009 at 8:47 PM, Kenton Varda ken...@google.com wrote:
Note that the protocol buffer parser is not asynchronous. That means
you
either need to feed it an entire message
usages because my message
stream is not strictly request/response. There can be multiple request
messages in a row, ditto for responses.
Regards,
Brodie
On Jun 19, 12:47 pm, Kenton Varda ken...@google.com wrote:
On Thu, Jun 18, 2009 at 8:47 PM, Kenton Varda ken...@google.com
wrote
Currently, no, that is not supported. I'm happy to accept a patch which
adds the ability to use infinity and nan as default values for doubles
and floats.
On Fri, Jun 19, 2009 at 6:53 AM, dragan mihajlovic
mihajlovic.dra...@gmail.com wrote:
Hi.
Is there a way to specify NaN as a default
Sorry, Protocol Buffers do not provide support for searching or indexing.
All protobuf does is parse and serialize data structures. Drizzle is
actually building database functionality *on top* of protocol buffers --
they implement their own searching and indexing, using protocol buffers to
201 - 300 of 1054 matches
Mail list logo
