Ah, I just use reply-all in gmail to make sure the group gets CC'd on stuff.
On Thu, Nov 5, 2009 at 4:44 AM, Marc Gravell marc.grav...@gmail.com wrote:
My apologies; I thought I had already replied to this. It turns out
gmail and google-groups look too similar, but only one gets back to
the
, 2009 at 9:17 AM, Evan Jones ev...@mit.edu wrote:
On Nov 2, 2009, at 12:14 , Kenton Varda wrote:
There's no convention for this currently.
It would be pretty nice to have the parser parse some form of doc
comments. Then the language backends could output them appropriately:
javadoc for Java
No. A DescriptorPool is simply a cache in front of a DescriptorDatabase. A
DescriptorDatabase can be arbitrarily large -- perhaps infinitely large --
therefore we do not provide a way to enumerate it. You should find a design
which does not require enumerating the entire pool.
2009/11/1 Romain
What you want to do is create a MapDescriptor, Message which maps from
descriptors to default instances of each of your generated classes. For
example:
MapDescriptor, Message myMap = new ...;
myMap.put(FooMessage.getDescriptor(), FooMessage.getDefaultInstance());
Are you sure the problem isn't simply that you've enabled certain pedantic
warnings? I strongly doubt that GCC 4.4 actually requires explicit
initialization of superclasses as this would break lots and lots of code.
On Fri, Oct 30, 2009 at 10:13 AM, Oleg Smolsky o...@smolsky.net wrote:
Hey
On Fri, Oct 30, 2009 at 10:36 AM, PaulH paul.h...@gmail.com wrote:
OPTIONAL is already defined in windef.h. At the top of
extension_set.cc, add this:
#ifdef UNDER_CE
#ifdef OPTIONAL
#undef OPTIONAL
#endif
#endif
Or you can just simply write:
#undef OPTIONAL
since it's going to be a
, this is certainly not a protobuf issue, as it is my code that uses
-Wextra. The option brings many good checks, but one of them is completely
retarded. Arg!...
Thanks!
Oleg.
On 10/30/2009 10:32 AM, Kenton Varda wrote:
Are you sure the problem isn't simply that you've enabled certain pedantic
I would guess that the GCC version is the problem. If you can find a
work-around, submit a patch!
On Thu, Oct 29, 2009 at 1:32 AM, eggxp egg...@gmail.com wrote:
OS Version:
[r...@localhost root]# cat /proc/version
Linux version 2.4.20-8smp (bhcomp...@porky.devel.redhat.com) (gcc
version
Protocol buffers has no concept of null. Fields cannot be set to null. You
can *clear* a field, like:
builder.clearParamCountry();
This sets the field back to its default value (the empty string, unless you
declared some other default). Also, hasParamCountry() will return false
until you
It appears that your system lacks strtoll(). You'll need to replace it
somehow. Is your system 64-bit? If so, strtol() should work fine. There's
actually an #ifdef near the top of strutil.h which deals with this for other
systems.
As for the iter has already been declared problem, it looks
of injecting a middleman may not be a
problem.
I like the last idea because it is the most modular. Any other ideas?
On Wed, Oct 28, 2009 at 8:24 PM, Neil T. Dantam mechs...@gmail.com wrote:
Kenton Varda wrote:
Also, writing third-party code generators in languages other than C++ is
tricky
It looks like there are two Java ME implementations listed here:
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns
But if neither one works for you, you may have to work on one of them until
it does.
(I'm not too familiar with Java ME, but I assume that it can't handle the
official Java
There's a hack at the top of message.h to deal with this. I suppose it
should have been moved to message_lite.h when lite mode was introduced.
On Thu, Oct 22, 2009 at 2:41 AM, villintehaspam villintehas...@gmail.comwrote:
Hi,
I am having some troubles with protocol buffers 2.2.0 together
Hey, it's great that you're trying things. I think there's room for
improvement in the Java implementation (as opposed to C++), and it tends to
take some trial-and-error.
You note that small messages seem faster with smaller buffer sizes, but
larger messages are slower. I am guessing that by
: -42949672960
On Wed, Oct 21, 2009 at 5:27 PM, Kenton Varda ken...@google.com wrote:
The lite test does not actually test all the features of the lite runtime.
It only tests that the lite runtime works stand-alone. The full tests
verify other features (many of which are shared between the two
There is no .proto parser in Java. However, you can use protoc's
--descriptor_set_out flag to generate a FileDescriptorProto representing the
file (or use FileDescriptor::CopyTo() in C++). This is a protocol buffer
representation of everything defined in the .proto. In Java, you can then:
1)
First, change A.user to have the type bytes instead of string.
Then do this:
b.SerializeToString(a.mutable_user());
But why not declare user to be of type A instead? Like:
message A {
required B user = 1;
}
On Wed, Oct 21, 2009 at 1:11 AM, SuKai sukai090...@gmail.com wrote:
Hi All!
It looks like you are calling exit() from a signal handler. Lots of stuff
is not safe to do in signal handlers. You should perhaps use _exit()
instead to bypass destruction of global variables.
On Wed, Oct 21, 2009 at 6:04 AM, edan edan...@gmail.com wrote:
I have a bizarre and not very
'. Not sure why the
protobuf requires this when nothing else does... but regardless,
thanks for the pointer to pkg-config... it helped solve the problem
for me! :)
Thanks again!
-Rob
On Oct 21, 11:13 am, Kenton Varda ken...@google.com wrote:
When you compile a program against libprotobuf
: Death tests use fork(), which is
unsafe particularly in a threaded context. For thi.
Abort
On Wed, Oct 21, 2009 at 12:32 PM, Kenton Varda ken...@google.com wrote:
It seems there's some ambiguity as to whether -pthread implies -lpthread.
Are you able to compile and run the tests?
On Wed
= 4;
}
So , I want use R1's proto instance to encode this message on R2' proto
instance.
Can I get the true value for the same colums (user_b user_c) value?
Thanks.
Kenton Varda 写道:
On Wed, Oct 21, 2009 at 6:04 PM, SuKai sukai090...@gmail.com mailto:
sukai090...@gmail.com wrote
It sounds like you know what the problem is, so can you send a patch that
fixes this? Remember to add a test to zero_copy_stream_test.cc.
On Sun, Oct 18, 2009 at 9:27 AM, Jacob Rief jacob.r...@gmail.com wrote:
I use protobuf to write self delimited messages to a file. When I use
Due to spam getting bad on this group lately, I have changed the settings
such that the first message from a new user will be held for moderation.
Each user will only have to go through moderation once.
Please let me know how you feel about this -- we can change it back if
people think it is a
It looks like it is looking for x86 header files, which suggests that the
compiler thinks you are trying to compile for x86 rather than ARM.
On Mon, Oct 19, 2009 at 2:37 PM, JavaGuru gringol...@gmail.com wrote:
Im trying to build a static protobuff library to use with iPhone and
Im running
You can implement arbitrary comparison algorithms using reflection (protobuf
reflection, not Java reflection -- see the Message interface).
On Sat, Oct 17, 2009 at 10:34 AM, Michael michael...@hmamail.com wrote:
Thanks for the suggestion but unfortunately equals with not tell me GT
or LT.
On Sun, Oct 18, 2009 at 1:07 PM, jakob.v...@gbv.de siehea...@googlemail.com
wrote:
The Language Guide describes the string scalar data type as A
string must always contain UTF-8 encoded or 7-bit ASCII text. does
this include the ASCII control character below 0x20? At least XML does
not allow
real use.
On Sep 3, 12:58 pm, Kenton Varda ken...@google.com wrote:
[+gak]
On Thu, Sep 3, 2009 at 1:47 AM, Bjorn Borud bbo...@gmail.com wrote:
hi,
someone checked in a maven plugin earlier this year. are there any
plans to make this available through a Maven repository
about the damn unit tests. Just get the plugin out into the
wild and end the suspense. It's good to go as is, at least in my
experience. You'll undoubtedly get more exposure and testing done once
it's out in the world and has gotten some real use.
On Sep 3, 12:58 pm, Kenton Varda ken...@google.com
On Thu, Oct 15, 2009 at 11:45 AM, Mika Raento mi...@iki.fi wrote:
I have the protobuf lite code running on Symbian.
Neat.
It's around 100k
which although large by the platform standards, I can live with.
Is this the lite library or the full one? I'd suggest focusing on the lite
library
Can you upload your patch to codereview.appspot.com regardless? I'd like to
see what changes are required, and other Borland users could reuse your
patch.
On Thu, Oct 15, 2009 at 2:54 AM, Dazza dazzacoll...@gmail.com wrote:
It turns out that the namespace internal causes problems for the
What language are you using?
In C++:
Object obj;
for (int i = 0; i array1_size; i++) {
obj.add_pair()-set_key(array1[i]);
}
if (obj.pair_size() == array2_size) {
for (int i = 0; i array2_size; i++) {
obj.mutable_pair(i)-set_value(array2[i]);
}
} else {
// error
}
On Wed, Oct 14,
Can you send a patch? Assuming the changes are not intrusive I'd be happy
to merge this back into the main distribution. (Although I can't guarantee
that it won't break again over time since we don't test on this platform.)
On Tue, Oct 13, 2009 at 9:53 PM, Dazza dazzacoll...@gmail.com wrote:
Thanks, I've added this to the list:
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns
On Tue, Oct 13, 2009 at 1:40 PM, Yura Mamyrin y...@yura.net wrote:
hello
ive made a page about it :D
http://swingme.sourceforge.net/encode.shtml
thanks
-YURA
http://yura.net/
Kenton Varda wrote
Unfortunately, we (read: I) don't really have time to chase warnings. If
you want it fixed, submit a patch. Otherwise, ignore it -- the code does
the right thing.
On Fri, Oct 9, 2009 at 1:16 AM, Jesper jesper.eskil...@gmail.com wrote:
The Eclipse Java compiler issues a warning about a raw
On Thu, Oct 8, 2009 at 10:57 AM, sergei175 sergei...@googlemail.com wrote:
1) After event 500, even 200MB memory is not enough.
2) It's slower by factor ~5 compare to the java serialization with
the
compression.
Protocol Buffers do not include compression, so to make this comparison
Yikes. That's kind of like someone left you with just .class files without
the .java files.
If you look at the code, though, you will notice that there are comments in
it defining each field, like:
// optional int32 i = 1;
These should be the exact field definitions as they might appear in the
, Kenton Varda ken...@google.com wrote:
Yikes. That's kind of like someone left you with just .class files
without
the .java files.
If you look at the code, though, you will notice that there are comments
in
it defining each field, like:
// optional int32 i = 1;
These should be the exact
On Wed, Oct 7, 2009 at 5:46 AM, villintehaspam villintehas...@gmail.comwrote:
I am wondering about the best way of forwarding received protocol
buffer messages from one entity to another without having to parse the
entire message just to serialize it again.
It looks like you've figured out
:33 PM, Brenden Matthews bren...@diddyinc.comwrote:
Here you go...attached is an example that fails quite reliably (for me).
Compile like so:
mkdir build
cd build
cmake ../
make
./test-pb
On Wed, Oct 7, 2009 at 4:49 PM, Kenton Varda ken...@google.com wrote:
ByteSize() definitely returns
On Tue, Oct 6, 2009 at 9:34 AM, Brenden Matthews bren...@diddyinc.comwrote:
it specifies that if you are dealing in messages larger than a
megabyte each, it may be time to consider an alternate strategy.
My question is: does this apply to messages which are large because
they themselves
and transfer it to you.
- Dave
On Mon, Sep 28, 2009 at 7:00 PM, Kenton Varda ken...@google.com wrote:
I've added this to the list of implementations:
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns
Looks like we have two other Common Lisp implementations already, but
neither one
On Mon, Oct 5, 2009 at 10:33 AM, jaypipes jaypi...@gmail.com wrote:
I'm wondering what is the most efficient method to remove an element
from a Message's vector of repeated elements? I looked at the
RepeatedFieldPtr API but would appreciate some example code on how to
do this in the most
The easiest solution is to create an outer message like:
message NodeList {
repeated Node node = 1;
}
then write a single NodeList to the file, and read it back again as a single
NodeList.
If you really need to read/write individual messages separately (because the
file is too big to
using google::protobuf::Descriptor;
using google::protobuf::FieldDescriptor;
using google::protobuf::EnumDescriptor;
using google::protobuf::EnumValueDescriptor;
const Descriptor* descriptor = message.GetDescriptor();for (int i = 0; i
descriptor-field_count(); i++) {
const FieldDescriptor*
, then recurse, but would I have to handle single and repeatble
message fields differently?
field-is_repeated() returns true or false. There's nothing else different
about the descriptors (though the resulting messages are obviously pretty
different).
Thanks
On Oct 2, 1:59 pm, Kenton Varda ken
This has been discussed before but no one has gotten around to doing it.
I'd be happy to accept a patch which adds a method DontEscapeUtf8(bool) to
TextFormat::Printer. Of course, unprintable ASCII characters should still
be escaped.
On Wed, Sep 30, 2009 at 2:06 AM, Dmitry Ermolov
I don't know if the author of protobuf-c frequents this discussion group.
You might try e-mailing him directly.
On Tue, Sep 29, 2009 at 7:48 AM, zavi zav...@gmail.com wrote:
Hello,
I'm trying to compile protobuf-c and keep getting errors I didn't when
I tried compiling on other machines.
On Tue, Sep 29, 2009 at 12:22 PM, alopecoid alopec...@gmail.com wrote:
Hi,
Can serialized messages be used reliably as keys?
In other words, is it guaranteed that...
- Two equal messages will always generate equal byte sequences?
(Are fields always written in the same order?)
Only if:
On Tue, Sep 29, 2009 at 12:41 PM, alopecoid alopec...@gmail.com wrote:
But, as in my example, that doesn't seem to be the case (necessarily).
Again, for example, let's say you have two messages, both of the same
type. The proto defines two optional fields, both of type variable
int64.
Say
The configure script is generated by autoconf based on configure.ac. If you
can't trace your problems back to something wrong in configure.ac (or in the
m4 subdirectory) then you will probably need to talk to the autoconf
maintainers instead.
That said, cross compiling is supported, and I've used
On Mon, Sep 28, 2009 at 9:44 AM, Michi mtha...@ph.tum.de wrote:
Hello,
I have defined the following messages:
package myapp.proto.modules.diagnostics;
message DiagnosticsConfigMessage {
optional bool watchdog_enabled = 1;
optional uint32 watchdog_timeout = 2;
}
package
I've added this to the list of implementations:
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOnsLooks like we have
two other Common Lisp implementations already, but neither one appears to be
maintained. :/
On Sat, Sep 26, 2009 at
Have you looked at protobuf-c at all? Maybe it comes closer to your needs?
On Mon, Sep 28, 2009 at 3:48 PM, Andrzej Zawadzki a.zawad...@gmail.comwrote:
I think safe WinCE protobuf usage is currently impossible due to two
main reasons:
1. Assumption done in protobuf implementation that memory
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:
Jinx. :)
On Fri, Sep 25, 2009 at 10:04 AM, Henner Zeller h.zel...@acm.org wrote:
Maybe 'Free' is a macro defined in that compiler environment ? (would
be bad, but these things happen).
What happens if you do an #undef Free in front of that
On Fri, Sep 25, 2009 at 07:25, alex
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*
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
://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
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
501 - 600 of 1054 matches
Mail list logo
