Even if the message contains only one, non-repeated field, ParseFrom*() will
keep reading until EOF or an error.
At Google, we have lots of various container formats, for streaming,
record-based files, database tables, etc., where each record is a protocol
buffer. All of these formats store the
You should send the method's name along with the request. The receiver can
then look up the MethodDescriptor from the service's ServiceDescriptor,
using FindMethodByName().
You might even encode your messages like this:
message RpcRequest {
required string method_name = 1;
// The serialized
I don't think DLLs or LIBs created with a never version of MSVC will work
with MSVC 2003. Protobufs use STL heavily in the interface, and I think the
STL classes change from version to version.
On Tue, Sep 16, 2008 at 4:44 AM, Niall [EMAIL PROTECTED] wrote:
I get the same runtime error with
Even if only the implementation changes -- specifically, the class's memory
layout -- that will cause a binary incompatibility, especially since STL is
all templates. It seems the debug vs. release versions of MSVC's STL are
not even binary compatible, so being compatible between two versions of
I think you'll have to run it in a debugger and try to figure out the cause
of the crash you're seeing. I don't have a copy of MSVC '03, but if you
send me the stack trace I could try to guess what's going on.
On Tue, Sep 16, 2008 at 1:03 PM, Niall [EMAIL PROTECTED] wrote:
Finally. I see what
submitted. Thanks for prodding me into fixing this. :)
On Fri, Sep 19, 2008 at 6:41 AM, [EMAIL PROTECTED] wrote:
You can submit it, the code is correct.
Thank you.
--
*De :* Kenton Varda [mailto:[EMAIL PROTECTED]
*Envoyé :* 18 septembre 2008 17:13
On Fri, Sep 19, 2008 at 9:50 AM, Mars [EMAIL PROTECTED] wrote:
just want to find some sample code for Class Service:
http://code.google.com/apis/protocolbuffers/docs/reference/python/google.protobuf.service.Service-class.html
That's the Python version. Shouldn't you be looking at the Java
You probably shouldn't rely on this. Some of the serialization methods will
guarantee this, some won't. What you can do is call ByteSize() yourself,
and then use SerializeWithCachedSizes(), which requires that ByteSize() was
already called and won't call it again. You'll have to do a small
Unfortunately, the protocol buffer library was designed in an environment
where all code is statically-linked, and it probably won't work so well with
dynamically-loaded code. The problem is that at start-up, descriptors are
built for each compiled-in message type and registered in a singleton
It seems like something went wrong with the upload. When I look at the
side-by-side diffs it just says error: old chunk mismatch. Do you have
any idea what might have gone wrong?
On Wed, Sep 24, 2008 at 6:31 PM, Travis Pouarz [EMAIL PROTECTED] wrote:
On Sep 24, 7:17 pm, Kenton Varda [EMAIL
On Wed, Sep 24, 2008 at 4:37 PM, Travis Pouarz [EMAIL PROTECTED] wrote:
This first one reveals a disagreement about whether a directory name
should be followed by a slash:
[ RUN ] CommandLineInterfaceTest.OutputDirectoryIsFileError
Interesting ideas. Before we get too creative, though, let me say a word of
caution: if an option affects the generated code in all languages (e.g. by
changing the wire format), then it can't really be a custom option, since
it will have to be compiled into protoc anyway. I'm very wary about
Hi all,
Just before building the 2.0.2 release candidate, I submitted a change to
make static linking the default for the protobuf libraries under MSVC. This
seems necessary to avoid some of the problems inherent in DLLs which have
been discussed here, such as the fact that each DLL has a
You can use TextFormat for this. Say your file is going to have a set of
FooMessages in it. Then, define a message like:
message FooSet {
repeated FooMessage foo = 1;
}
Now, your file can look like this:
foo {
... contents of the first FooMessage ...
}
foo {
... the
Hi Chad,
First, please be aware that protobuf@googlegroups.com is a public mailing
list with non-Googlers on it. If you need to communicate anything
confidential or Google-specific, please e-mail the appropriate internal
mailing list.
Anyway, I'm afraid you're going to have to help out with
protobuf_BuildDesc_RequestHeader_2eproto() should be declared in
RequestHeader.pb.h. Is it not?
What exact flags are you passing to protoc?
On Thu, Oct 9, 2008 at 8:29 AM, [EMAIL PROTECTED] wrote:
I'm in the process of evaluating PB for a distributed cross language
project I'm on. I've
On Thu, Oct 9, 2008 at 12:52 PM, [EMAIL PROTECTED] wrote:
protoc.exe --cpp_out= [Fully qualified path name]
Ah, ok, you've identified a bug. protoc is supposed to reject any input
file which is not located within the import path. The import path is
specified using --proto_path and defaults
I'm not familiar with stlport. One thing you could try doing is editing
config.h manually and removing all the HASH_* #defines. Then the code will
fall back to using map instead of hash_map, which should work since map has
a standard interface.
On Fri, Oct 10, 2008 at 2:58 AM, [EMAIL PROTECTED]
Sorry, I'm not sure I understand the question. What, exactly, is the main
problem you're having?
On Fri, Oct 10, 2008 at 3:11 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED]wrote:
I have some kind of requirement that I did not find answer from the
document. May someone help me.
I have different
Are you sure that the data you are sending to the parser is exactly the same
data that was generated by the serializer? Remember that protocol buffers
are not self-delimiting, so you need to make sure that you limit the input
to the exact number of bytes that were produced when serializing.
If
On Mon, Oct 13, 2008 at 2:26 AM, edan [EMAIL PROTECTED] wrote:
I quick google didn't turn up much for me on what that actually means
- does it mean anything to y'all?
Yes, this was an overzealous warning present in one version of GCC which was
promptly toned down in subsequent versions. You
, Kenton Varda [EMAIL PROTECTED] wrote:
I'm not familiar with stlport. One thing you could try doing is editing
config.h manually and removing all the HASH_* #defines. Then the code
will
fall back to using map instead of hash_map, which should work since map
has
a standard interface
You can create a message like this:
message Container {
// One of the following will be filled in.
optional Ping ping = 1;
optional StatusUpdate status_update = 2;
optional FindWorker find_worker = 3;
}
Now send Containers over the wire instead of instances of the individual
message
Currently, no, you can only clear the whole list and start over. I would be
amenable to a patch, though, if people feel this would be a useful addition.
On Wed, Oct 15, 2008 at 8:36 PM, Andrew Wachira [EMAIL PROTECTED] wrote:
In the Java language.
On 10/15/08, Kenton Varda [EMAIL PROTECTED
/test.pb.h: while trying to create
directory ./C:: Invalid argument
C:/Projects/Apps_main/C++/Common/test.pb.cc: while trying to create
directory ./C:: Invalid argument
On Sep 2, 2:22 pm, Kenton Varda [EMAIL PROTECTED] wrote:
On Tue, Sep 2, 2008 at 10:06 AM, [EMAIL PROTECTED] wrote
I'm not sure how mac frameworks work, but it looks like your compiler is not
linking against the protobuf library.
On Thu, Oct 16, 2008 at 9:41 AM, Carlos Gamboa [EMAIL PROTECTED] wrote:
Hello. I am trying to add the protocol buffer to my application (for
iphone) and i have been struggling
Many (most?) servers at Google use asynchronous protobuf RPC. I'm not sure
how to answer your question, though. Can you be more specific?
On Tue, Oct 14, 2008 at 7:16 AM, muqu [EMAIL PROTECTED] wrote:
Anybody can shine some light on their experience on using the PB RPC
on an asynchronous
I've made this change in SVN. Thanks.
On Thu, Oct 2, 2008 at 12:40 PM, Caleb [EMAIL PROTECTED] wrote:
When run with high warning levels, gcc complains that the 'request'
and 'response' arguments are unused for all of the stub service
functions generated by the protoc compiler. Here's the
I don't see any obvious problems. Try printing the whole message just
before serializing and just after parsing to see if they are both as you
expect.
On Sat, Oct 18, 2008 at 11:24 PM, comsatcat [EMAIL PROTECTED] wrote:
I have a simple client server in python... I have the following
protobuf
For the first case, the problem is that the build is trying to run protoc as
part of the build process, and it's trying to use the cross-compiled protoc.
I think you can fix this by editing src/Makefile.am at line 201 to change
this:
unittest_proto_middleman: protoc$(EXEEXT) $(protoc_inputs)
I believe this was fixed in 2.0.2. What version are you using?
On Tue, Oct 21, 2008 at 11:21 AM, [EMAIL PROTECTED] wrote:
I have a protoc file named UniqueID.proto that is compiled into and
exported from Communication.dll.
I have a protoc file named Base.proto that is compiled into and
On Tue, Oct 21, 2008 at 12:13 PM, [EMAIL PROTECTED] wrote:
Would simply changing FileGenerator::GenerateHeader to output the
dllexport_decl in the forward declaration of BuildDescriptors function
work?
Yes, that is the fix.
--~--~-~--~~~---~--~~
You received
There is no built-in support for this, but there's nothing stopping you from
applying whatever compression you want to the serialized data.
On Tue, Oct 21, 2008 at 1:08 PM, GDR [EMAIL PROTECTED] wrote:
I noticed the protocol buffers store strings in their uncompressed
form. Is there any
On Wed, Oct 22, 2008 at 7:23 AM, Niclas Blomgren
[EMAIL PROTECTED] wrote:
Solaris:
I'm guessing this was a sparc system, not x86? Was it 32-bit or 64-bit? I
think someone else reported the same problem but we were not able to track
it down.
Cygwin:
Can you include the text of the actual
The Partial serialize and parse routines actually do something completely
unrelated: they allow the message to be missing required fields. So, that
doesn't help you.
I'm afraid protocol buffers are not designed for storing very large
collections in a single message. Instead, you should be
:* den 23 oktober 2008 09:50
*To:* 'Kenton Varda'
*Cc:* protobuf@googlegroups.com
*Subject:* RE: Make check reports error
Hi!
Solaris: Yes it was a sparc system. 64-bit.
Cygwin: Ok here it is. I have also attached the entire make check in a
logfile.
[ RUN
We do not provide a pre-compiled library because it is important that you
use a version of the library compiled with the same compiler version which
you will be using with your own code. Even on Windows, different versions
of MSVC have slightly different STL implementations. Since the protocol
From the command line, you can do:
protoc --decode_raw data_file
This will give you as much information as can be determined without a type
definition, to give you an idea of what's there. In C++, you can use the
UnknownFieldSet class to parse and inspect a message of unknown type.
On Wed,
STL strings never shrink. When they're cleared, they keep their memory
around for reuse. So, you could take advantage of that to accomplish what
you want by setting all your string fields to values of the maximum size and
then clearing them. For example:
StaticSizeMsg msg;
In general, protocol buffers can be used to encode individual chunks within
a stream, but representing the entire stream as a protocol buffer won't work
very well.
On Thu, Oct 23, 2008 at 8:14 PM, sureshkk [EMAIL PROTECTED] wrote:
Hi,
I am looking at a use case where one needs to transfer
The reasoning for unknown enums being treated as unknown fields goes
something like this:
We cannot simply use an unknown numeric value since many languages do not
allow enum types to represent numeric values other than the set of values
explicitly defined for them. Furthermore, even if they did,
Oh, the implicit default for enums is the first defined value, not zero.
On Fri, Oct 24, 2008 at 3:03 PM, Marc Gravell [EMAIL PROTECTED]wrote:
Makes sense - it just seems a little odd that the optional enums don't
have a valid default...
Marc
Added to my todo list.
On Sat, Oct 25, 2008 at 1:19 AM, Marc Gravell [EMAIL PROTECTED]wrote:
Ah! Right. That makes more sense. Could that perhaps be added to the
language guide Optional Fields And Default Values?
Marc
--~--~-~--~~~---~--~~
You received
Can you give a specific example of a complete protoc command and the error
it produces? protoc should not care about spaces in file names as long as
they are properly quoted.
On Mon, Oct 27, 2008 at 6:49 AM, sdx [EMAIL PROTECTED] wrote:
Hi,
While trying to invoke the protoc compiler on the
It would be pretty easy to write code that serializes or parses java
protocol message objects in JSON format using the protobuf reflection
interface (see the Message and Builder interfaces). I don't know of any
existing implementations, though.
On Sun, Oct 26, 2008 at 2:11 PM, Richard [EMAIL
The protocol buffer format expects you to remember where the message ends;
it cannot figure out for itself. So, you need to write the size of each
message to your file before you write the message itself.
On Mon, Oct 27, 2008 at 11:42 AM, Amit Gupta [EMAIL PROTECTED] wrote:
I have message
[+petar]
On Mon, Oct 27, 2008 at 10:47 AM, andres [EMAIL PROTECTED] wrote:
Hi,
I would like to use protocol buffers in my python code but currently
the serialization and parsing methods are too slow compared to
cPickle. I've read several posts stating that this is because the
python
I'm not sure I understand. What would you expect the import line importing
a_pb2 to look like? My understanding is that Python imports are absolute,
not relative to the importing file.
On Sat, Oct 25, 2008 at 7:11 PM, Alan Kligman [EMAIL PROTECTED]wrote:
I'm having a problem with protoc
I don't really have a stake in the design of a protobuf-based RPC format.
However, I'd like to point out that the design philosophy we tend to prefer
at Google is to keep each layer of the system as simple as possible, and
implement orthogonal features using separate layers. Authentication is a
on the output from protoc, which could get nasty.
On Oct 27, 5:44 pm, Kenton Varda [EMAIL PROTECTED] wrote:
I'm not sure I understand. What would you expect the import line
importing
a_pb2 to look like? My understanding is that Python imports are
absolute,
not relative to the importing file
The protoc code is licensed under the New BSD license, which is extremely
permissive. You will have to include a copyright notice but that's about
it. Read COPYING.txt for the full license -- it's quite short.
On Fri, Oct 31, 2008 at 2:30 PM, Marc Gravell [EMAIL PROTECTED]wrote:
(probably one
The version with a single repeated field (which presumably you expect to
always have size 16) will be slightly more efficient on the wire and
significantly more efficient in-memory (assuming you're using C++).
I think you'll find the single repeated field version more usable, too --
you can
You would have to define each message in a separate .proto file.
On Thu, Nov 6, 2008 at 1:37 AM, [EMAIL PROTECTED] wrote:
Hi guys!
I'm a new user.
Can somebody kindly tell me how do I generate classes in separate
files (h' and cpp' files for each message)?
Thanks!
Omer
Hi Jeff,
I've read your message a few times now and I have to admit I don't really
understand what you're getting at. Can you give a small example of each of
the approaches you're considering?
On Wed, Nov 5, 2008 at 12:06 AM, codeazure [EMAIL PROTECTED] wrote:
Does anyone have any thoughts on
I just submitted revision 72, which fixes the bug that caused the tests to
crash on 64-bit sparc machines. It turns out DynamicMessage computed some
byte offsets incorrectly leading to alignment problems. The new code should
be more robust.
I'll probably do a 2.0.3 release within the next week
The Python implementation currently does not require any non-Python
libraries at runtime. You'll probably have to try it to see if it works on
Symbian, though. :)
On Fri, Nov 7, 2008 at 5:15 AM, Maximilian [EMAIL PROTECTED]wrote:
Hi,
Is it possible, to use Protobuf for python on Python for
I don't know Python very well. Petar, can you verify this is correct? (I
tried it and the tests still pass.)
On Thu, Nov 6, 2008 at 11:43 PM, Pavel Shramov [EMAIL PROTECTED] wrote:
In 2.4, 2.5 and 2.6 superclass constructor call don't need self as first
arg
but 2.6 raises error if it's
Yes, I believe you. We just have a policy of reviewing all changes. :)
On Fri, Nov 7, 2008 at 11:19 AM, Pavel Shramov [EMAIL PROTECTED] wrote:
On Fri, Nov 07, 2008 at 10:04:27AM -0800, Kenton Varda wrote:
I don't know Python very well. Petar, can you verify this is correct?
(I
tried
On Mon, Nov 10, 2008 at 9:12 AM, Chris Kuklewicz [EMAIL PROTECTED]wrote:
BUG * The user-defined options have the wrong value for some 32 bit
value.
Looks like you figured this out. Yeah, the idea is that 32-bit varints and
64-bit varints should always be compatible. So, if you write a
On Tue, Nov 11, 2008 at 7:46 AM, ChJees [EMAIL PROTECTED] wrote:
I managed to solve my problem now. I used the blah.Bytesize() function
instead of sizeof( blah.c_str() ) when sending the message size :3.
Ah, yes, don't use c_str() with serialized protobufs because they may
contain zeros
You don't have to worry about the uninterpreted_option field. It's an
internal implementation detail of the parser. You should pretend it isn't
there.
The comment is saying that the uninterpreted_option field must have the name
uninterpreted_option in all *Options messages because the parser
Sorry, the docs are not actually stored in HTML form. They are EZT
templates, so if we did make them downloadable you'd have to run an EZT web
server to view them. The best we could do otherwise would be to spider them
ourselves. So I don't think there's much worth doing here.
On Wed, Nov 12,
BTW, you didn't have to rename your .proto file. You could have just used
the java_outer_classname to make it produce a different class name.
On Thu, Nov 13, 2008 at 11:40 AM, Kenton Varda [EMAIL PROTECTED] wrote:
You're using the java_multiple_files option, I take it?
The outer class
I agree, the setters should either throw NPE or should treat setFoo(null)
the same as clearField().
On Thu, Nov 13, 2008 at 7:39 AM, bivas [EMAIL PROTECTED] wrote:
Hi,
I'm using the Java output feature of protobuf for my app.
I found that protobuf doesn't handle null values as well as i
Good news: There was a patch for this submitted to the internal version of
the code which should make its way to SVN today or tomorrow, and will be in
the 2.0.3 release.
On Wed, Nov 19, 2008 at 1:29 AM, Jerry Cattell [EMAIL PROTECTED]wrote:
I'm trying to use a custom EnumValueOption:
when constructing an
RpcChannel.
On Wed, Nov 19, 2008 at 5:06 PM, codeazure [EMAIL PROTECTED] wrote:
On Nov 20, 7:58 am, Kenton Varda [EMAIL PROTECTED] wrote:
I'm not sure I understand. There's nothing stopping you from spreading
your
definitions out among multiple .proto files which import
This is a bug that has been fixed in SVN and will be fixed in the 2.0.3
release, which should happen soonish. If you don't use DynamicMessage you
don't need to worry about it.
On Thu, Nov 20, 2008 at 11:34 AM, Nimisha Mishra
[EMAIL PROTECTED] wrote:
Hello,
I have installed protocol
I just committed SVN revision 76 which integrates a bunch of changes from
our internal codebase (see below). 2.0.3 will probably be released next
week.
protoc
* Enum values may now have custom options, using syntax similar to field
options.
* Fixed bug where .proto files which use custom
I just put a release candidate here:
http://groups.google.com/group/protobuf/files
Test and tell me what's broken.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send
On Mon, Dec 1, 2008 at 6:46 PM, aantono [EMAIL PROTECTED] wrote:
message Person
java_implement_interface = com.domain.Name;
required string name;
required int32 age;
}
More precisely:
message Person {
option java_implement_interface = com.domain.Name;
required string name = 1;
] wrote:
On Dec 2, 10:49 pm, Kenton Varda [EMAIL PROTECTED] wrote:
C++ compatibility matters because eventually we want to be able to
generate
Python code which just wraps C++ code for efficiency. C++ isn't
garbage
collected, so append() can't easily be implemented in this case without
an issue?
-dave
On Dec 3, 2:41 pm, Kenton Varda [EMAIL PROTECTED] wrote:
Ehhh... Reference counting is slow (assuming it needs to be
thread-safe),
and I think even adding it as an option would add an excessive amount of
complication to the system.
On Wed, Dec 3, 2008 at 2:04 PM, Dave
It's quite easy to write a helper function that reads/writes delimited
messages (delimited by size or by end tag).
For example, here's one for writing a length-delimited message:
bool WriteMessage(const Message message, ZeroCopyOutputStream* output) {
CodedOutputStream coded_out(output);
On Fri, Dec 5, 2008 at 10:59 PM, Alek Storm [EMAIL PROTECTED] wrote:
On Wed, Dec 3, 2008 at 5:32 AM, Kenton Varda [EMAIL PROTECTED] wrote:
Sorry, I think you misunderstood. The C++ parsers generated by protoc
(with optimize_for = SPEED) are an order of magnitude faster than the
dynamic *C
On Sun, Dec 7, 2008 at 3:45 AM, nightwalker leo [EMAIL PROTECTED]wrote:
when I try to parse an addressbook file which has 2^20 records of
person , my program complains like this:
libprotobuf WARNING D:\protobuf-2.0.2\src\google\protobuf\io
\coded_stream.cc:459] Reading dangerously large
Hey Petar, isn't there a patch someone was trying to submit that implements
text format parsing? (For real, not by wrapping protoc.) What's the status
of that?
On Mon, Dec 8, 2008 at 5:03 AM, Nicholas Reid [EMAIL PROTECTED] wrote:
Hi All,
Firstly, just wanted to thank Kenton and the Google
On Sat, Dec 6, 2008 at 1:03 AM, Alek Storm [EMAIL PROTECTED] wrote:
But it does give us a lot of cool functionality, like adding the same
message to two parents, and (yes!) slicing support. I thought this was
common practice in C++, but it's been quite a while since I've coded it.
Nope, in
to
have access to current and complete documentation - doesn't have to be
a huge amount, but just something to remind us that it's there.
Thanks,
Jeff
On Dec 6, 5:48 am, Kenton Varda ken...@google.com wrote:
protoc
* Enum values may now have custom options, using syntax similar to
field
On Tue, Dec 16, 2008 at 2:27 AM, atulatri2...@gmail.com wrote:
Hi,
I have couple of questions regarding protocol buffers in java
1. I am using old bean style data structures. How can i migrate to
protocol buffers and what problems may arise due to this migration.
This is a pretty broad
inary package.
2008/12/3 Kenton Varda ken...@google.com:
You need to run setup.py from the directory where it resides.
On Tue, Dec 2, 2008 at 11:51 PM, EYN pengshengw...@gmail.com wrote:
I can not install it:
C:\Python25python C:\Python25\protobuf-2.0.3rc1\python\setup.py
install
OK, I'll stick it on my TODO list. Feel free to send me a patch if you want
it done faster. :)
On Tue, Dec 16, 2008 at 10:53 PM, sorent
soren.torstens...@tietoenator.comwrote:
Definitely a better idea better :-)
/Sören
--~--~-~--~~~---~--~~
You received
and
send it independently - works fine.
Weird...
Thanks for the dialog.
On Dec 17, 9:36 am, Kenton Varda ken...@google.com wrote:
If you write a program demonstrating the problem and send it to me, I
can
debug it.
On Wed, Dec 17, 2008 at 11:10 AM, Ryan ryanroll
Size-wise, the only difference between your Lite structure and the current
protobuf classes is that it wouldn't have a virtual table pointer or a
cached byte size. Do these really make that much difference?
On Wed, Dec 17, 2008 at 9:11 PM, Shaun Cox shaun8...@gmail.com wrote:
As stated by
I can't reproduce this problem. What compiler are you using? Can you
provide example code which demonstrates the problem?
On Mon, Dec 22, 2008 at 2:18 AM, ufukalti...@gmail.com wrote:
Btw, i'm using the latest svn version of the compiler and library
On Dec 20, 11:28 pm,
On Thu, Dec 25, 2008 at 6:10 PM, Chris turingt...@gmail.com wrote:
There is a small type on the web page about the custom options:
optional int32 foo = 1 [(my_field_option = 4.5)];
should be
optional int32 foo = 1 [(my_field_option) = 4.5];
Thanks, I'll fix this.
On Sat, Jan 3, 2009 at 7:32 PM, Dave Wolfe dwolfe5...@hotmail.com wrote:
FYI, it looks like a few new functions are missing __declspec()
decorators. I had to apply the trivial patch below in order to
build a DLL version of protobuf under Windows. (This applies to
both 2.0.3 and the current
Did the tests pass or fail? The tests explicitly test the code which
produces those warnings, so seeing them is expected. As long as the tests
report that they passed you are fine.
On Mon, Jan 5, 2009 at 12:12 PM, mikesparr...@gmail.com
mikesparr...@gmail.com wrote:
Starting a clean
5, 2009 at 4:38 PM, Kenton Varda ken...@google.com
mailto:ken...@google.com wrote:
Hmm, works for me. This may sound silly, but try deleting all your
google.com-related cookies. I've seen redirect loops in google
services fixed by this before.
As a matter of fact, IE
How would that work, exactly?
On Wed, Jan 7, 2009 at 11:50 AM, mikesparr...@gmail.com
mikesparr...@gmail.com wrote:
Is there an existing convert that can take a header file and produce
a .proto file?
--~--~-~--~~~---~--~~
You received this message because
Protocol buffers are useful even if all users are using the same language.
In fact, we used them in C++ for some time before anyone bothered writing
Java and Python implementations.
On Wed, Jan 7, 2009 at 3:43 PM, Alek Storm alek.st...@gmail.com wrote:
Mike, what exactly are you trying to
On Wed, Jan 7, 2009 at 5:39 PM, Alek Storm alek.st...@gmail.com wrote:
Right, I guess I didn't explain why they don't work in this case.
Generating .proto files from C++ headers is obviously the reverse of
the normal sequence. In the PB method of versioning, the
original .proto is written
I believe there was a proposal internally that if the caller passes None for
the callback, the RPC implementation should block until completion and then
return the result. Does that seem like what you want?
On Wed, Jan 7, 2009 at 6:23 PM, Alan Kligman alan.klig...@gmail.com wrote:
I poked
, 10:02 pm, Kenton Varda ken...@google.com wrote:
I believe there was a proposal internally that if the caller passes None
for
the callback, the RPC implementation should block until completion and
then
return the result. Does that seem like what you want?
On Wed, Jan 7, 2009 at 6:23 PM
To give the same answer as Alek with slightly different wording:
The accessors for extensions are analogous to the accessors for a normal
field. For a normal message-type field, there is no set accessor. There
is only mutable. For example:
// Proto
message Foo {
optional Bar bar = 1;
.
On Jan 12, 2:08 pm, Kenton Varda ken...@google.com wrote:
Hmm, you're probably right that the arguments should have used hyphens
rather than underscores. That said, we certainly can't just change it
without breaking people, and accepting both seems hacky.
On Mon, Jan 12, 2009 at 10:19 AM
Read all the bytes into a buffer, then parse the buffer once you have the
whole thing.
On Mon, Jan 12, 2009 at 4:11 PM, chongyc chongy...@gmail.com wrote:
Thank you very much for your help.
I want parsing string 's' by reading each a byte from s.
What is alternative way that you can
Send the size of the message first, then the data.
On Mon, Jan 12, 2009 at 4:34 PM, chongyc chongy...@gmail.com wrote:
When I send multiple messages, I should delimit them, and parse the
buffer.
What is the best way delimitting it that you can recommend me ?
On Jan 13, 8:18 am, Kenton
On Mon, Jan 12, 2009 at 5:27 PM, Alek Storm alek.st...@gmail.com wrote:
I'm for changing it. Command line flags get deprecated in software
all the time.
Only for good reasons. This isn't a good enough reason to deprecate. So
the options are between having just the underscore versions or
On Mon, Jan 12, 2009 at 8:32 PM, Dave Bailey d...@daveb.net wrote:
I agree, and it seems to be a question that comes up frequently in
this forum, so maybe we should add a page to the Wiki that discusses
how to send and receive a stream of protobuf (or any) messages.
I did add some
, Kenton Varda ken...@google.com wrote:
On Wed, Dec 3, 2008 at 10:14 AM, gregg greggh...@gmail.com wrote:
What's the status of the packed option for repeated fields? Is this
still intended for a future protobuf release? I searched for packed
and the last post in this group about
1 - 100 of 1054 matches
Mail list logo
