Odd... it's as if addressbook.pb.cc's static initializers were run twice
(so it was registered in the global descriptor pool twice, and on the second
instance you saw the error).
Can you run in a debugger, set a breakpoint at
DescriptorPool::InternalBuildGeneratedFile(), and see what calls it, and
from
// a file descriptor or an istream since these interfaces don't provide
// a way to push data back into the stream if we read too far.
I'm pretty swamped, though. Does someone want to write up a patch (with
unit tests)?
On Sat, Sep 6, 2008 at 2:44 AM, <[EMAIL PROTECTED]> w
On Mon, Sep 8, 2008 at 4:33 AM, <[EMAIL PROTECTED]> wrote:
> More tricky. Given a stream and an instance, I'm trying to get the
> Descriptor by calling Message#getDescriptorForType() on the instance
> and passing the return value, along with an input stream, to
> DynamicMessage#parseFrom(Descript
Protocol Buffers solve the problem of converting structured data into a flat
byte array. They do not solve the problem of communicating that byte array
over a network; that's the job of some other library. Sorry to disappoint.
On Sun, Sep 7, 2008 at 10:58 AM, Mateusz Berezecki <[EMAIL PROTECTED]
;wrote:
> On Mon, Sep 8, 2008 at 7:26 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> > Protocol Buffers solve the problem of converting structured data into a
> flat
> > byte array. They do not solve the problem of communicating that byte
> array
> > over a networ
On Mon, Sep 8, 2008 at 6:18 PM, Alex Loddengaard
<[EMAIL PROTECTED]>wrote:
> On Tue, Sep 9, 2008 at 1:16 AM, Kenton Varda <[EMAIL PROTECTED]> wrote:
>
>> That won't work. DynamicMessage is a different class; it does not know
>> how to instantiate the protoco
On Mon, Sep 8, 2008 at 6:27 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, Sep 8, 2008 at 6:18 PM, Alex Loddengaard <
> [EMAIL PROTECTED]> wrote:
>
>> On Tue, Sep 9, 2008 at 1:16 AM, Kenton Varda <[EMAIL PROTECTED]> wrote:
>>
>>>
On Mon, Sep 8, 2008 at 9:11 PM, Alex Loddengaard
<[EMAIL PROTECTED]>wrote:
> I have a follow-up question:
>
> Will using
> *messageInstance.newBuilderForType().mergeFrom(input).build();*work for a
> stream that contains trailing binary information?
>
No, it won't work. Protocol buffers are not
eserialize from contains trailing binary data?
>>
>> Thanks ahead of time for your help.
>>
>> Alex
>>
>>
>> On Tue, Sep 9, 2008 at 10:47 AM, Alex Loddengaard <
>> [EMAIL PROTECTED]> wrote:
>>
>>> After taking my code out of Hadoop, it
Regarding speed, make sure you have:
option optimize_for = SPEED;
in your .proto file. (The default is to optimize for code size, since
people should only optimize for speed after profiles show that they need
it.)
Regarding reading only part of a file: Protocol buffers are designed to be
parsed
Note that the inefficiency of repeated primitive types will be fixed...
eventually... but, yeah, right now it's no good.
On Fri, Sep 12, 2008 at 2:09 AM, Chris <[EMAIL PROTECTED]> wrote:
>
> Nicolas wrote:
> > Can anyone with some experience in these matters, and especially of
> > alternative f
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 si
nts from a list seems to be
> > awful hacks like a.parse(a.serialise()) after clearing the items you
> > want to delete
> >
> > On Aug 12, 9:05 pm, "Kenton Varda" <[EMAIL PROTECTED]> wrote:
> >
> > > For C++, use the RepeatedField inter
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
On Mon, Sep 15, 2008 at 6:14 PM, Leandro Lucarella <[EMAIL PROTECTED]> wrote:
> I understand your concern but I don't think looking after the user should
> stay in the way of flexibility. I surely prefere flexibility than people
> looking after me just in case I can't meassure the consequences.
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 M
On Tue, Sep 16, 2008 at 12:26 PM, Niall <[EMAIL PROTECTED]> wrote:
> But, suppose you have the dll, a lib and the required header files.
> You have all the things you need. The functions, their location, how
> they are called. Surely the DLL would worry about itself. It's a
> separate moster altog
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 w
It sounds like output_ is not a valid pointer. What's the full stack trace?
On Tue, Sep 16, 2008 at 1:25 PM, Niall <[EMAIL PROTECTED]> wrote:
>
> For some reason the debugger didn't even come to mind...
>
> OK. It crashes at the 'bool
> OstreamOutputStream::CopyingOstreamOutputStream::Write( con
It's the list of function calls which lead to the point of the crash.
On Tue, Sep 16, 2008 at 1:48 PM, Niall <[EMAIL PROTECTED]> wrote:
>
> What's the stack trace?
>
> If it's the debugging output this is what I have:
>
> 'protobuf_test.exe': Loaded 'C:\Documents and Settings\Niall\My
> Documents
I believe I've seen people report these errors when using very old versions
of GCC. What version of GCC / what OS are you using?
On Wed, Sep 17, 2008 at 4:20 AM, dd shan <[EMAIL PROTECTED]> wrote:
>
> ./configure
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether
Ugh. More evidence that libprotobuf should be statically-linked, not a DLL.
Niall: Maybe this explains your problem. Can you try compiling static libs
only and see if that fixes anything?
On Tue, Sep 16, 2008 at 9:31 PM, mcdowella
<[EMAIL PROTECTED]>wrote:
>
> There are at least two problems w
Use the callback:
Message response =
responsePrototype.newBuilderForType.mergeFrom(data).build();
done.run(response);
On Thu, Sep 18, 2008 at 12:07 PM, Java Jogger <[EMAIL PROTECTED]> wrote:
>
> I just started looking at implementing RPC service in Java. In my
> implementation class of RpcC
Any comments on the code? If not, I'll go ahead and submit it.
On Thu, Sep 18, 2008 at 1:59 PM, <[EMAIL PROTECTED]> wrote:
> Yes, is working.
>
> ==> Test ok on Tru64 (with some other changed in the code for the
> compiler)
> ==> Test ok on Windows Visual Studio 2005
>
> Issue 5682 can be ignore
Yes, currently that's how it works. C++ and Python work this way too.
On Thu, Sep 18, 2008 at 1:43 PM, Jie Yao <[EMAIL PROTECTED]> wrote:
>
> I see. The java RPC implementation has to be async via call back, is
> that right?
>
> Jie
>
> On Sep 18, 2:15 pm,
ne.run(response)
>
> returns only the expected response under successful scenarios.
>
> Jie
>
> ----- Original Message
> From: Kenton Varda <[EMAIL PROTECTED]>
> To: Jie Yao <[EMAIL PROTECTED]>
> Cc: Protocol Buffers
> Sent: Thursday, September 18, 2
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 :*
You'll have to stick some sort of one-byte tag on the front of the message
to identify which type it is.
On Fri, Sep 19, 2008 at 11:05 AM, BeamMeUpScotty <[EMAIL PROTECTED]>wrote:
>
> We're looking at a scenario where there could possibly be many
> different messages on the same wire. For exampl
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
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 amoun
Use the Makefile. If you don't have make, then don't worry about it and
compile and run the Java files like you would any Java executable class.
add_person_java is really just an alias for "java AddPerson".
On Mon, Sep 22, 2008 at 8:16 AM, Adrian <[EMAIL PROTECTED]> wrote:
>
> I was able to ins
I think the documentation should be changed; I'll fix that. However,
negative enum values should probably be discouraged as they will always be
encoded as 10 bytes on the wire.
On Mon, Sep 22, 2008 at 3:08 AM, Chris <[EMAIL PROTECTED]> wrote:
>
> There is a disagreement between the documentation
On Fri, Sep 19, 2008 at 7:39 PM, Leandro Lucarella <[EMAIL PROTECTED]> wrote:
>
> Kenton Varda, el 19 de septiembre a las 16:12 me escribiste:
> > You probably shouldn't rely on this. Some of the serialization methods
> will
> > guarantee this, some won'
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
reg
I've added this to the wiki.
On Mon, Sep 22, 2008 at 3:50 PM, Dave Bailey <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I've uploaded my Perl/XS code generator for Protocol Buffers:
>
> http://code.google.com/p/protobuf-perlxs
>
> This is a work in progress, of course. I have gotten this to work on
> m
I've submitted this patch (or something equivalent, anyway). Sorry for the
delay.
On Sat, Sep 6, 2008 at 12:08 AM, Mats Kindahl <[EMAIL PROTECTED]> wrote:
> Kenton Varda wrote:
> > I don't think GCC generates this warning with -Wall and -Werror alone.
> > Maybe
Please re-send your question to the appropriate Google-internal mailing
list. protobuf@googlegroups.com is populated by people who are not Google
employees and is not an appropriate place to discuss internal code or
documentation. Luckily your message doesn't contain anything sensitive, but
since
Hi all,
We've decided to change the license for Protocol Buffers from Apache 2.0 to
BSD. In general we like the Apache 2.0 license better, but unfortunately it
is not compatible with GPLv2. We decided that allowing GPLv2 projects to
use protocol buffers is more important, so we're switching. I'
Playerlist also has methods:
const RepeatedPtrField& player() const;
RepeatedPtrField* mutable_player();
RepeatedPtrField is documented here:
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.repeated_field.html
It has methods which allow you to add an existing objec
Hi all,
I just submitted revision 50 and 51 to SVN, including these changes:
General
* License changed from Apache 2.0 to New BSD.
* It is now possible to define custom "options", which are basically
annotations which may be placed on definitions in a .proto file.
For example, you mi
Thanks. Can you send this to me via codereview.appspot.com?
On Wed, Sep 24, 2008 at 4:25 PM, Travis Pouarz <[EMAIL PROTECTED]> wrote:
> based on 2.0.1 release since I
> don't see any Subversion repos of trunk
What do you mean?
http://protobuf.googlecode.com/svn/trunk/
--~--~-~--~
pported for consistency.
On Thu, Sep 25, 2008 at 9:18 AM, Chris <[EMAIL PROTECTED]> wrote:
> I can support the new options in Haskell right after I finish the unknown
> field loading/storing/writing.
> But work is busy right now, so I won't estimate how long I will take.
>
>
compatible anyways.
>
> Why did you decide against GPLv3?
>
> 2008/9/24 Kenton Varda <[EMAIL PROTECTED]>
>
>> Hi all,
>>
>> We've decided to change the license for Protocol Buffers from Apache 2.0
>> to BSD. In general we like the Apache 2.0 licen
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 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
> google/protobuf/compiler/command_line_interface_u
I still only see the first patch set.
On Thu, Sep 25, 2008 at 4:29 PM, Travis Pouarz <[EMAIL PROTECTED]> wrote:
>
>
> > >http://codereview.appspot.com/6051
>
> On Sep 25, 1:12 pm, "Kenton Varda" <[EMAIL PROTECTED]> wrote:
> > It seems like some
Apparently codereview.appspot.com allows over-zealous browser caching. I
had to refresh. I see it now. Will review tonight or tomorrow.
On Thu, Sep 25, 2008 at 5:37 PM, Travis <[EMAIL PROTECTED]> wrote:
>
> On Sep 25, 2008, at 6:51 PM, Kenton Varda wrote:
>
> I still only s
08 at 7:40 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> Apparently codereview.appspot.com allows over-zealous browser caching. I
> had to refresh. I see it now. Will review tonight or tomorrow.
>
>
> On Thu, Sep 25, 2008 at 5:37 PM, Travis <[EMAIL PROTECTED]> wrote:
OK, let me know when it's in. Thanks!
BTW, if your changes haven't been submitted to upstream gtest, I'll make
sure they get there.
On Fri, Sep 26, 2008 at 6:53 AM, Travis <[EMAIL PROTECTED]> wrote:
>
> Which just leaves the legal annoyance... Have you signed the contributor
>> license agreeme
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 a
llo Kenton,
> >
> > Thanks a lot! That is exactly what I was looking for!
> >
> > Regards,
> > Rico
> >
> > On 24 Sep., 18:56, "Kenton Varda" <[EMAIL PROTECTED]> wrote:
> >
> > > Playerlist also has methods:
> >
[cc Dave Benson, author of the C bindings]
On Mon, Sep 29, 2008 at 2:05 AM, Doron Tal <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm new to protobuf, and I want to use the new c binding. However,
> compilation does not pass.
>
> Thanks for your help,
> Doron
>
> [doron-lx] protobuf-c-0.4 > make
> Mak
Hi all,
I've put up a release candidate for v2.0.2 here:
http://groups.google.com/group/protobuf/files
It is also tagged in SVN:
http://protobuf.googlecode.com/svn/tags/release-2.0.2rc1/
Please test it if you have a moment. Assuming no one finds any problems,
I'll do the official release in a c
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 separate
The code generated by protoc requires linking against the protobuf
libraries, so the Protocol Buffers license terms apply to you either way. I
can talk to our licensing people and get this clarified if you want, but
given this, does it still matter? BTW, v2.0.2 (to be released later this
week) wi
I don't have any plans to support VC6, but if someone does the port and
submits a patch I'll be happy to apply it (assuming it doesn't harm other
platforms).
On Mon, Sep 29, 2008 at 8:37 PM, Angus <[EMAIL PROTECTED]> wrote:
>
> I'm working on several VC6 client server projects and want to migrate
Our lawyer's opinion seems to be that the generated code is owned by the
owner of the input file by default, even without a special note. However,
I've added a note to COPYING.txt anyway to make it completely clear.
http://protobuf.googlecode.com/svn/trunk/COPYING.txt
On Tue, Sep 30, 2008 at 10:2
The reason I specified automake-1.9 explicitly is because our corp
workstations actually have the regular "automake" command linked to
automake-1.4, which is not good enough. automake-1.9 is installed on our
workstations, but is not the default. Can we somehow auto-detect this
situation and do so
After some offline discussion I've gone ahead and submitted this.
On Tue, Sep 30, 2008 at 11:40 AM, Jeff Bailey <[EMAIL PROTECTED]> wrote:
>
> The autogen.sh script has all sorts of hardcoded magic in it,
> including the version of the autotools, and the fact that we're
> requiring "foriegn" mode
in the
> libtool and automake M4 macros. Checked with automake-1.9/
> autoconf2.59 and automake1.10/autoconf2.61
>
> On Sep 30, 1:56 pm, "Kenton Varda" <[EMAIL PROTECTED]> wrote:
> > After some offline discussion I've gone ahead and submitted this.
> >
&g
Submitted.
Note: Google groups word-wraps input, which can break patches.
On Tue, Sep 30, 2008 at 2:58 PM, Jeff Bailey <[EMAIL PROTECTED]> wrote:
>
> The following patch fixes one obsolete construct in configure.ac and
> neurotically adds quoting. Because I <3 m4.
>
> Tested with automake-1.9/a
name to the prefix by changing "." to "__"; for deeply nested
> package names, this convention is too verbose.
>
>
>
> On Sep 26, 11:31 am, "Kenton Varda" <[EMAIL PROTECTED]> wrote:
> > Interesting ideas. Before we get too creative, though,
In which language? In Java you can just use .equals(). In C++, you could
serialize the two and compare the bytes. Alternatively, you could write
some code that iterates over the fields via reflection and compares them.
On Wed, Oct 1, 2008 at 9:13 AM, <[EMAIL PROTECTED]> wrote:
>
> What's the "
I'm not really familiar with Java 1.1 so I'm not sure I can provide much
advice here.
There are lots of things you could potentially strip out, depending on your
needs. You might want to decide whether your app would rather use
optimize_for = SPEED or optimize_for = CODE_SIZE in general. Optimizi
Done.
On Thu, Oct 2, 2008 at 10:55 AM, yas <[EMAIL PROTECTED]> wrote:
>
> Hi project owners,
>
> I've just started a project for a protocol buffers encoder/decoder
> written in JavaScript.
>
> http://code.google.com/p/protobuf-js/
>
> To tell the truth, I don't think it's very useful. but I'm gla
Sorry, you're just a little bit too late. I just put up the new release.
On Fri, Oct 3, 2008 at 11:59 AM, Jon Skeet <[EMAIL PROTECTED]> wrote:
>
> On Sep 30, 1:41 am, "Kenton Varda" <[EMAIL PROTECTED]> wrote:
> > I've put up a release candidate for v
http://code.google.com/p/protobuf/downloads/list
I forgot to strip the win32 binary in the first upload, making for a
ginormous download. Hence the -a. :/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol B
Argh, that was a mistake. They should use the same version. And 2.0.1
should really have been 1:0:0.
I'm not very good at this maintenance thing...
Unfortunately, due to the nature of C++, it's unlikely that any two versions
of the library will be binary-compatible.
On Mon, Oct 6, 2008 at 11:08
On Mon, Oct 6, 2008 at 10:36 AM, Chris <[EMAIL PROTECTED]> wrote:
> Kenton Varda wrote:
>
>> I'll be updating the documentation to explain this better soon. It's a
>> bit complicated. Check out unittest_custom_options.proto for an example.
>> Let
Well, the code is correct C++, so it's hard to tell what might convince the
compiler to accept it.
Does it work if you change this:
typename DescriptorT::OptionsType* options =
tables_->AllocateMessage();
To this:
typedef typename DescriptorT::OptionsType OptionsType;
OptionsType* op
Petar, can you look into this?
On Sun, Oct 5, 2008 at 2:47 AM, <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm trying to install and test out protobuf-2.0.2. I read the
> instructions in python/README.txt and ran
> $ python setup.py test
>
> And I get
>
> =
[+petar]
(Same problem as the other thread.)
On Sun, Oct 5, 2008 at 2:41 AM, Iustin Pop <[EMAIL PROTECTED]> wrote:
>
> Hi there,
>
> Revision 50 changed the following line in
> python/google/protobuf/internal/decoder_test.py:
>
> 122: ['sfixed32', decoder.Decoder.ReadSFixed32, -1,
> 'ReadLit
Done and submitted. Thanks.
On Sun, Oct 5, 2008 at 3:42 AM, Iustin Pop <[EMAIL PROTECTED]> wrote:
>
> Currently, the python example program list_people.py has a slightly
> different output than the others, so you can't use it to test that all
> languages give the same output.
>
> The following p
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 secon
We use C-style escaping in both the .proto language and TextFormat. The
only difference from C string literals is that the outer quotes may be
either single or double quotes (as long as they match).
On Tue, Oct 7, 2008 at 5:05 AM, Marc Gravell <[EMAIL PROTECTED]> wrote:
>
> It doesn't seem expli
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 this,
OK, based on sephacryl's message I created this patch, but I suspect edan's
problem is actually different. Can you both try it out and tell me if it
works? edan, if this doesn't solve the problem for you, can you try making
some changes yourself and figure out what works?
Index: src/google/protob
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 c
enerated files in Drizzle rather than being able to
> have just the .proto files.
>
> Thanks!
>
> On Aug 26, 6:23 pm, "Kenton Varda" <[EMAIL PROTECTED]> wrote:
> > Thanks. I'll apply this after 2.0.1 release, which has been pending for
> > some time bloc
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 defaul
Looks like a bug to me. Thanks for catching it.
On Fri, Oct 10, 2008 at 10:19 AM, Jon Skeet <[EMAIL PROTECTED]> wrote:
>
> On Oct 10, 5:33 pm, Jon Skeet <[EMAIL PROTECTED]> wrote:
> > Anyone fancy pointing out my stupid mistake?
>
> Got it!
>
> Not only does options.proto need to import google/p
Extensions work analogously to the generated accessors you'd see for a
normal field of the same type. So, for a message-typed field, there is no
"set" accessor. Instead, there is a "mutable" accessor. So, you want to
do:
Request request;
Renderer* renderer = request.MutableExtension(Renderer
md file is that the [inputs] macro from VS
> provides the .proto file to the command line using a relative path.
> The cmd file takes the relative path and expands it out to a fully
> qualified path, filename and extension and passes it to protoc.
>
>
> On Oct 9, 5:00 pm, &qu
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 diffe
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 the
My apologies for not having added this to the FAQ page yet. Too many little
things to do... :(
On Sun, Oct 12, 2008 at 10:18 AM, Chris <[EMAIL PROTECTED]> wrote:
>
> This is a FAQ.
>
> [EMAIL PROTECTED] wrote:
> > Hi, Kenton,
> >
> > The main problem is how can I serialize two different objects
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. Y
th protobuf.
> how can i do?
>
> On 10月11日, 上午4时24分, "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
> wi
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 types
Yeah, I think special-casing descriptor.proto might be the only way. :(
On Tue, Oct 14, 2008 at 12:28 PM, Jon Skeet <[EMAIL PROTECTED]> wrote:
>
> One of the major benefits of descriptor.proto, as I saw it, was that
> we could get away from the hard-coded extra options as there are for
> Java.
>
In which language?
On Wed, Oct 15, 2008 at 1:50 AM, Andy <[EMAIL PROTECTED]> wrote:
>
> Hi,
> We can push values onto repeated fields. Is there a way of popping
> values from the same?
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribe
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, Kento
>
> C:/Projects/Apps_main/C++/Common/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 PR
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 strugglin
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 asynchronou
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
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
> prot
The code generated by protoc is identical on all platforms, so you can use
the same protoc that you compiled for Linux. You only have to cross-compile
the libprotobuf library. Cross-compiling should work exactly like it does
with any other autoconf-based package.
On Mon, Oct 20, 2008 at 6:58 AM,
1 - 100 of 1581 matches
Mail list logo
