It looks like your protobuf library and protocol compiler binary are from
different releases. This won't work. Please make sure both are upgraded to
2.1.0, the latest release.
On Tue, Jul 14, 2009 at 8:52 AM, Michael Stapleton
mike.staple...@echostar.com wrote:
Hi All,
I am using release
Answered in the other thread -- you need to use matching protoc and protobuf
library versions.
On Tue, Jul 14, 2009 at 2:57 PM, Mike mike.staple...@echostar.com wrote:
I am getting the error
com.google.protobuf.Descriptors.FileDescriptor.InternalDescriptorAssigner
cannot be resolved to a
suggestions?
Thanks Regards,
Vikram
On Jul 13, 5:23 pm, Kenton Varda ken...@google.com wrote:
And yes, I'd love a patch. :)
On Mon, Jul 13, 2009 at 5:22 PM, Kenton Varda ken...@google.com wrote:
google/protobuf/stubs/hash.h already contains some hacks for hash_map.
To
support
I don't think that's currently implemented in Python, unfortunately.
On Mon, Jul 13, 2009 at 8:28 AM, Ferenc Szalai szf...@wsbricks.com wrote:
Hi
There is any plan to implement DescriptorPool class in python?
Especially, I missing easy way to transform FileDescriptorProto to
Descriptor in
and shift to unordered_map and
then put in a mapping/typedef for hash_map if something doesn't have u_m?
(Kenton - would you be interested in a patch doing that?)
On Jul 1, 12:00 pm, Kenton Varda ken...@google.com wrote:
Well, it looks like all of these are stuck in the same place
And yes, I'd love a patch. :)
On Mon, Jul 13, 2009 at 5:22 PM, Kenton Varda ken...@google.com wrote:
google/protobuf/stubs/hash.h already contains some hacks for hash_map. To
support unordered_map, all we'd have to do is add another hack there which
defines hash_map to be a subclass
Speed varies a lot depending on the precise content. My benchmarks
generally show serialization performance somewhere between 100 MB/s and 1
GB/s, whereas you're seeing 33MB/s, but my benchmarks do not include any
kind of I/O. Maybe you could separate the serialization step from the I/O
(by
Oh, I didn't even know you were including composition in there. My
benchmarks are only for serialization of already-composed messages.
But this still doesn't tell us how much time is spent on network I/O vs.
protobuf serialization. My guess is that once you factor that out, your
performance is
On Fri, Jul 10, 2009 at 3:12 AM, bart van deenen
bart.vandee...@gmail.comwrote:
However, when I try to build my application with -Lpath/to/
libprotobuf.a I get hundreds of linker errors, complaining about
undefined references to any of the google protocol functions.
You need to use:
Run in a debugger and set a breakpoint at wire_format_inl.h:289.
On Thu, Jul 9, 2009 at 1:56 PM, Rizzuto, Raymond raymond.rizz...@sig.comwrote:
I think I have an error in my code (C++) that only occurs when I have
multiple threads, and a lot of message volume. Even then, I can run the
same
.
--
*From:* Kenton Varda [mailto:ken...@google.com]
*Sent:* Thursday, July 09, 2009 5:02 PM
*To:* Rizzuto, Raymond
*Cc:* protobuf@googlegroups.com
*Subject:* Re: intermittent issue with encode (version 2.0.3)
Run in a debugger and set a breakpoint at wire_format_inl.h:289.
On Thu
+= , ;
error += *it;
}
throw SPException(error.c_str());
}
It might not be something I’d do in production, but it sure would help
during development.
--
*From:* Kenton Varda [mailto:ken...@google.com]
*Sent:* Thursday, July 09
Sorry, I think I misread your message.
You just want there to me a method like IsInitialized() that you can call to
validate UTF-8 stuff. I'll think about that.
On Thu, Jul 9, 2009 at 2:32 PM, Kenton Varda ken...@google.com wrote:
This is something you can do in your own code -- just call your
passes through its declaration” means when two threads call the function
simultaneously. Perhaps gcc4 provides features that make that safe. I
don’t know if that is something that can be relied on in all compilers,
however.
Ray
--
*From:* Kenton Varda
The javadoc for ExtensionRegistry discusses the reasons why we didn't take
the auto-populated approach as was done in C++. In fact, I sort of wish we
had done something like ExtensionRegistry in C++ as well, as I get a lot of
messages from people who are confused why their program behaves
OK, I'll make the #if check the version number in the next release.
On Tue, Jul 7, 2009 at 12:15 AM, Cosmin Cremarenco
cosmin.cremare...@gmail.com wrote:
It is 1310
On Jul 6, 7:49 pm, Kenton Varda ken...@google.com wrote:
What's the _MSC_VER for that version?
On Mon, Jul 6, 2009 at 10
This is most likely a bug in your code -- you probably aren't transmitting
the message correctly. Please make sure that the bytes you give to the
protobuf parser on the receiving end are exactly the same bytes that were
produced by the serializer at the sending end -- both the size and contents
The purpose of default values is to define what the getter methods for those
fields return when the field is not set. This is really the only purpose.
We do not serialize default values because it would be a waste of space.
On Sat, Jul 4, 2009 at 1:47 PM, Zl D zlatko.zla...@gmail.com wrote:
You have to flush the CodedOutputStream.
You should just do this instead:
byte[] data = person.build().toByteArray();
On Thu, Jul 2, 2009 at 12:44 AM, J.V. jvsr...@gmail.com wrote:
I'm trying to get the following to work but nothing is being written to
the output stream.
any ideas?
Just call writeTo():
void writeToStream(Message message, OutputStream out) {
message.writeTo(out);
}
On Thu, Jul 2, 2009 at 7:47 AM, J.V. jvsr...@gmail.com wrote:
Which class in the ProtoBuf Java api would be used to encode to a binary
stream?
Is there a short example or tutorial on how
Protoc treats \r as plain whitespace, so it should have no problem with
Windows line endings. I just tested this and sure enough, protoc works fine
with .proto files that use Windows-style line endings.
Mac pre-OSX line endings (\r with no \n) won't work if the file contains any
comments.
What
.
thanks
jrv
Kenton Varda wrote:
You have to flush the CodedOutputStream.
You should just do this instead:
byte[] data = person.build().toByteArray();
On Thu, Jul 2, 2009 at 12:44 AM, J.V. jvsr...@gmail.com
mailto:jvsr...@gmail.com wrote:
I'm trying to get the following
protoc actually expects its input to be UTF-8 (though non-ASCII characters
are only allowed in default values for string fields). It just doesn't like
the BOM.
On Thu, Jul 2, 2009 at 12:44 PM, Marc Gravell marc.grav...@gmail.comwrote:
My bad... it isn't the line endings - it is the UTF8 BOM;
If you want to write up a patch to recognize a UTF8 BOM and ignore it, go
ahead. You can just modify the Tokenizer class to recognize and discard a
BOM appearing at the beginning of the input.
On Thu, Jul 2, 2009 at 1:31 PM, Marc Gravell marc.grav...@gmail.com wrote:
OK... is there any way it
Done and done.
I didn't know protobuf-net had RPC or I would have listed it on the RPC
implementations page some time ago.
On Thu, Jul 2, 2009 at 1:47 PM, Marc Gravell marc.grav...@gmail.com wrote:
I notice the replacement ThirdPartyAddOns page; can you please also
include protobuf-net in the
What's the difference between all these links?
On Thu, Jul 2, 2009 at 4:08 PM, Chris Kuklewicz turingt...@gmail.comwrote:
Kenton,
Could you change the link on the
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns
page for Haskell from
Yeah, I think it's broken.
In reflection.py there is a line:
return decoder.Position() - content_start
I think (untested) that it should actually be:
return decoder.Position() - initial_position
I have no idea how this got past testing and I have asked the people
responsible to fix it.
On Thu, Jul 2, 2009 at 5:33 PM, Alex Black a...@alexblack.ca wrote:
I'm on windows, using Visual Studio 2008 SP1, compiling a Release x64
build of libprotobuf. The lib file is 29,570KB big, is that
expected?
I was going to say no way, but sure enough, the 32-bit release build is
18,154k, so
You'd have to ask the AppEngine people. Someone from that team submitted
the input_stream.py change.
The problem is that both protocol buffers and AppEngine place themselves in
the google package. Protocol Buffers has, from day one, declared the
package as a namespace package using setuptools,
it would happen.
On Wed, Jul 1, 2009 at 10:18 AM, J.V. jvsr...@gmail.com wrote:
thanks, which product(s) does Google use internally or find most
beneficial?
Kenton Varda wrote:
You could look at one of the open source RPC implementations listed here:
http://code.google.com/p/protobuf
crash when executing).
Thanks for the quicks answer.
Regards,
rodrigob.
On Jun 30, 1:01 am, Kenton Varda ken...@google.com wrote:
Sorry, I don't see what the problem could be.
Make sure that you are compiling libprotobuf and your project with the
same
C runtime version (e.g. debug vs
In order to *use* the Java implementation, you need to build that same C++
code -- the protocol compiler. The Java protobuf runtime is mostly useless
without it. However, you can get a prebuilt copy of protoc.exe for windows
here:
Protocol Buffers provides a way to convert between flat byte arrays and
structured data. This is obviously useful for network communication, but
protocol buffers does not provide any explicit networking support. It's up
to you to take the byte array generated by protocol buffers and send it over
Well, it's *supposed* to work as you say. But honestly, this code has not
been tested with blocking streams, since that's not how we use it in Google.
It's possible that there is a bug. But the code appears to be correct
AFAICT.
When CodedInputStream needs more data, it calls Refresh(), which
the Importer
class. This ultimately leaves me with a ServiceDescriptor. I'd like
to instantiate that Service from the ServiceDescriptor.
The python code has a ServiceStubBuilder class. Where is there a
ServiceStubBuilder in the C++ API?
On Jun 30, 1:33 pm, Kenton Varda ken...@google.com wrote
to do this ?
What sort of service would I need to be running on a server to send
data (and have the server receive and convert the flat byte array into
a Java object).
On Jun 30, 2:32 pm, Kenton Varda ken...@google.com wrote:
Protocol Buffers provides a way to convert between flat byte arrays
? Why not just call RpcChannel directly
instead?
On Jun 30, 2:08 pm, Kenton Varda ken...@google.com wrote:
Oh, you want something like DynamicMessage except for services?
DynamicServiceStub, perhaps? There is no such thing included in the
library, but it would be really trivial to write
it to send data over the
network and use on the other end.
In fact is this not what it was invented for (communication).
On 30 jun, 16:07, Kenton Varda ken...@google.com wrote:
There are tons of resources on the internet and in books explaining how
to
do network programming in Java. Sorry
insights regarding this
Thanks Regards,
Vikram
On Jun 26, 6:00 pm, Kenton Varda ken...@google.com wrote:
This isn't telling me much. Can you interrupt and continue a few times
to
get a few different stack traces, in order to find out what the common
part
of the trace is? This should
Simply adding a mutex lock in every accessor wouldn't really make them
thread-safe. Consider:
if (my_message.has_foo()) {
DoSomething(my_message.foo());
}
This is not thread-safe if my_message can be modified in a separate thread
*even if* each accessor locked a mutex, because foo could
.
This problem is being a show stopper for us, any help will be greatly
appreciated...
Regards,
rodrigob.
On Jun 26, 9:25 pm, Kenton Varda ken...@google.com wrote:
The stack trace you provided looks like it is from v2.0.3. The
initialization code changed drastically in 2.1.0 -- the method
On Sun, Jun 28, 2009 at 7:30 AM, Alex Black a...@alexblack.ca wrote:
Hi, I'm trying to use these to serialize messages to my own stream.
I have a couple of questions:
1. If I use message.SerializeToCodedStream() do I still need to write
the size of the message to the stream on my own
No, that doesn't make sense.
I need to see the exact code, from the point where the CodedOutputStream is
constructed until it is destroyed.
On Mon, Jun 29, 2009 at 5:35 PM, Kenton Varda ken...@google.com wrote:
Odd. By any chance, does this only happen when writing a zero-length
message
The stack trace you provided looks like it is from v2.0.3. The
initialization code changed drastically in 2.1.0 -- the method
DescriptorPool::InternalBuildGeneratedFile no longer exists, for example.
Can you provide a stack trace using 2.1.0?
On Fri, Jun 26, 2009 at 8:07 AM, rodrigob
is uses proto files seems like running in infinite loop. I am
currently looking at it
Vikram
On Jun 26, 12:32 pm, Kenton Varda ken...@google.com wrote:
On Thu, Jun 25, 2009 at 6:59 PM, vikram patilvik...@gmail.com wrote:
Hello guys,
I am actually attempting to compile
Yes, groups are never going to fully go away. But we recommend against
using them in new code.
On Thu, Jun 25, 2009 at 9:13 AM, Piotr Findeisen
piotr.findei...@gmail.comwrote:
Hi!
On Jun 24, 8:42 pm, Kenton Varda ken...@google.com wrote:
The end-tag approach is more efficient than your
BTW, this was also reported awhile ago as issue 86:
http://code.google.com/p/protobuf/issues/detail?id=86
On Thu, Jun 25, 2009 at 12:55 PM, Kenton Varda ken...@google.com wrote:
The problem is that GCC emits two or three copies of each constructor. In
order to keep generated code size down
One problem with javascript and protobuf is that you need a lot of support
code to parse the messages. Unless you end up sending quite a lot of stuff
back and forth, making the user download a JS protobuf codec library may be
a net loss. It may be better to use JSON or XML because browsers
It will be treated like an unknown field. In C++ or Java, the value goes
into the UnknownFieldSet, so if you then serialize the message, it will
still be there. In Python it will just be discarded.
On Wed, Jun 24, 2009 at 2:56 AM, Stuart Johnson stu...@stu.org.uk wrote:
If a new enum value
If the tests pass, it should be good to go. Please do submit patches.
On Wed, Jun 24, 2009 at 2:09 PM, vikram patilvik...@gmail.com wrote:
I was finally able to compile it correctly and evaluate its
correctness using tests.
Kenton,
Is there anything else I need to evaluate before
Did you call ShutdownProtobufLibrary() before checking for leaks?
As it says, the memory in question is still reachable, so whether or not it
is a leak is debatable. ShutdownProtobufLibrary() will go around and
delete all the objects the library has allocated. It's a huge waste of time
if
The advantage of writing the length is that a parser can skip the entire
sub-message easily without having to parse its contents. Otherwise, we
would probably use the group encoding for sub-messages, where a special
end tag marks the end of the message.
On Tue, Jun 23, 2009 at 9:06 AM, etorri
You can use UnknownFieldSet, but be warned that the interface for that class
is likely to change in a future version (because the current design is
somewhat inefficient). If you just want to print the contents, you should
be fine -- just parse into an UnknownFieldSet and then call its toString()
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
in this post.
Vikram
On Jun 4, 1:42 pm, Kenton Varda ken...@google.com wrote:
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
, 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
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
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
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
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
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
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
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 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
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
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,
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
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,
) ? 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
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*
, 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
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
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
701 - 800 of 1054 matches
Mail list logo
