On Wed, May 20, 2009 at 12:35 AM, cosmin.cremare...@gmail.com wrote:
./google/protobuf/stubs/once.h, line 114: Warning (Anachronism):
Formal argument 2 of type extern C void(*)() in call to pthread_once
(_once*, extern C void(*)()) is being passed void(*)().
This warning seems to be saying
at Google.
IMO, you should provide a --cross-compile option so the build knows when to
not run tests… Or, better yet, use the auto-tools to detect
cross-compilation environments and auto-disable testing…
Reid
*From:* Kenton Varda [mailto:ken...@google.com]
*Sent:* Friday, May 15, 2009 9
On Wed, May 20, 2009 at 10:44 AM, Monty Taylor mo...@inaugust.com wrote:
Kenton Varda wrote:
On Wed, May 20, 2009 at 12:35 AM, cosmin.cremare...@gmail.com
mailto:cosmin.cremare...@gmail.com wrote:
./google/protobuf/stubs/once.h, line 114: Warning (Anachronism):
Formal
If your compiler transforms string literals to a non-ASCII character set,
then the code generated by the protocol compiler won't work. We could
perhaps fix this by escaping every character in the embedded descriptor, but
other problems might come up. I don't have enough experience with EBCDIC to
You sent me a personal e-mail to which I replied. My reply was that I
unfortunately don't have time to review any large amount of code, but I'm
happy to put this on the list anyway if you'd like.
On Mon, May 18, 2009 at 7:36 PM, xiliu.t...@gmail.com
xiliu.t...@gmail.comwrote:
Any update on
The code does not compile in VS2k8.
Did you try replacing the using namespace std; with a bunch of individual
using std::Foo; directives? Can we work around the problem that way?
On Mon, May 18, 2009 at 11:56 AM, Zachary Turner divisorthe...@gmail.comwrote:
I managed to get it down to a
On Sun, May 17, 2009 at 6:57 AM, Chris Kuklewicz turingt...@gmail.comwrote:
I am patching the Haskell implementation and I have a follow up
question to this:
On May 14, 12:06 am, Kenton Varda ken...@google.com wrote:
* The type name resolver will no longer resolve type names to fields
I cannot reproduce this problem in MSVC 2008.
Are you using precompiled headers? Could it relate to that?
What happens if you replace using namespace std; with a bunch of usign
std::Foo; lines covering everything used by libprotobuf?
On Mon, May 18, 2009 at 11:34 AM, Zachary Turner
Any comment, Petar?
On Fri, May 15, 2009 at 7:21 AM, Nicholas Reid njr...@gmail.com wrote:
Hi Petar Kenton,
Have there been any recent developments on the Python C
implementation? I'd be more than happy to run a prototype through its
paces for testing purposes and provide feedback - it
On Thu, May 14, 2009 at 4:08 PM, reid.mad...@tektronix.com wrote:
There's only one problem with this. It assumes that you have a locally
compiled and installed the protoc compiler. Thus, before building a
cross-compiled version, one must also build a native version. This is an
unnecessary
On Fri, May 15, 2009 at 5:06 PM, reid.mad...@tektronix.com wrote:
Kenton,
The flaw in your assumption is that I actually use the current machine to
build my product. I don't.
I'm cross-compiling on platform A (redhat) for deployment on platform B
(mips). Other than the
Yes, linking against pthreads is required. Technically it always was, but
on certain platforms (e.g. Linux), it just happened that the set of pthread
functions used by libprotobuf were all implemented in libc itself, so if you
forgot to use -lpthead it worked anyway.
I suppose that should be in
FYI: This is fixed in the 2.1.0 release (you can call
google::protobuf::ShutdownProtobufLibrary() to clean up all leaks).
On Fri, Mar 27, 2009 at 7:07 PM, Kenton Varda ken...@google.com wrote:
On Fri, Mar 27, 2009 at 4:30 PM, Oleg Smolsky o...@smolsky.net wrote:
So, the next question
http://code.google.com/p/protobuf/downloads/list
Aaaand, I just realized that CHANGES.txt still has the release date as .
:(
/me is not very good at release engineering.
Oh well.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
Here's the major changes (from CHANGES.txt):
General
* Repeated fields of primitive types (types other that string, group, and
nested messages) may now use the option [packed = true] to get a more
efficient encoding. In the new encoding, the entire list is written
as a single byte
Updated documentation covering all this has been submitted and should go
live in a couple hours.
http://code.google.com/apis/protocolbuffers/docs/overview.html
On Wed, May 13, 2009 at 4:06 PM, Kenton Varda ken...@google.com wrote:
Here's the major changes (from CHANGES.txt):
General
serialisation to a
stream then?
Thanks again for the help.
Dan
On May 12, 5:26 pm, Kenton Varda ken...@google.com wrote:
Protocol Buffers has a bytes type. That's what it's talking about.
Just
change string to bytes in your .proto file. (They work exactly the
same
in C
In v2.1.0 I've added a parameter to the configure script --with-protoc=
which lets you specify an alternate protoc binary to use when compiling.
This way, the makefiles won't invoke the protoc they just built. So,
cross-compiling should work.
However, I haven't actually tested this with
On Tue, May 12, 2009 at 12:28 PM, Marc Gravell marc.grav...@gmail.comwrote:
What implementation are you using? Given that most of the
implementations use code-generation (rather than reflection), I'm
wondering if this is protobuf-net?
(since that supports inheritance by representing it as
Yes, use descriptors and the reflection interface. What language are you
using?
On Tue, May 12, 2009 at 1:31 PM, ajoy ajo...@gmail.com wrote:
I'm trying to write a recursive function that goes thru all fields of
a message. Without hardcoding anything, is there a way to retrieve all
repeated
On Tue, May 12, 2009 at 2:34 PM, ajoy ajo...@gmail.com wrote:
Thanks!
I'm using C++
got around mainly with the help of reflection-FieldSize(*message,
field) and reflection-GetRepeatedMessage(*message, field, j);
That's the way to do it.
On May 12, 2:27 pm, Kenton Varda ken
What do you mean? It seems to me that they should be written the same way
you'd write any other unit test in Python.
On Mon, May 11, 2009 at 3:51 AM, ssmai...@gmail.com wrote:
Hi,
Can anyone tell me how to proceed with writing Python Unit test cases
for Protocol Buffers. It would be great
On Fri, May 8, 2009 at 9:49 PM, clinton.fos...@quest.com wrote:
It was necessary to add a length prefix to the request/response
messages in order to remove the dependency on closing the connection
to know when the protobuf was finished being read. Also, since
Message.Builder.mergeFrom()
On Fri, May 8, 2009 at 7:08 AM, Peter K. koots...@gmail.com wrote:
1. MS Dev Studio 2008 converts the project on opening the solution
file.
Yep, that's expected -- we distribute MSVC 2005 project files (and gtest's
are MSVC 2003).
2. cl : Command line warning D9035 : option 'Wp64' has
What does your protoc command-line look like? Does your project contain
multiple .proto files that import each other? If so you need to make sure
to pass the same -I (or --proto_path) flag to each one.
On Fri, May 8, 2009 at 5:47 AM, Peter K. koots...@gmail.com wrote:
Hi All,
OK, so we've
On Fri, May 8, 2009 at 9:03 AM, Henner Zeller h.zel...@acm.org wrote:
fixed32 or fixed64 would be probably better. uint32 is encoded in
variable length which would make bitfields typically larger than
necessary.
Depends. If you are only using the first few (low-order) bits, then uint32
is
at 6:41 PM, Peter K. koots...@gmail.com wrote:
On May 8, 5:04 pm, Kenton Varda ken...@google.com wrote:
What does your protoc command-line look like? Does your project contain
multiple .proto files that import each other? If so you need to make
sure
to pass the same -I (or --proto_path
On Tue, May 5, 2009 at 8:15 PM, Hong Zhang h...@google.com wrote:
Hi, Kenton,
I am not familiar with protobuf compiler, so my comment may be off.
Since existing code does something like this.
static class Foo {
Foo() { ... }
} foo;
Actually, a lot of code doesn't look like that
Added to http://code.google.com/p/protobuf/wiki/RPCImplementations
On Tue, May 5, 2009 at 10:26 PM, Jun Tsai jun.t...@gmail.com wrote:
Protocol Buffers RPC Server Implemention based on Mina(2.0-M5) and
Protobuf(2.0.3).
I had implemented a protocol buffers rpc server.
Thanks, committed as revision 138.
On Wed, May 6, 2009 at 12:26 PM, jas...@google.com wrote:
Looks good!
On 2009/05/06 19:05:36, kenton wrote:
Addressed comments (see below) and synced, new patch set uploaded.
http://codereview.appspot.com/53053/diff/1/5
File
Write the field like this:
optional .foo.Foo foo = 1;
The leading period tells the compiler that foo refers to the foo at the
global scope (i.e. the package), not the foo in the current scope (the
field). (It's the same semantics and C++ namespaces.)
This is also fixed in version 2.1.0 --
to be flipped from multi-threaded to multi-threaded DLL,
otherwise the linker gets upset. I forgot to do this after my last update
of the gtest code.
On Wed, May 6, 2009 at 2:34 PM, Kenton Varda ken...@google.com wrote:
Hi all,
I've uploaded release candidate 2.1.0rc1 here:
http
Are you, like Fedor, linking to the CRT statically (/MT)? If so, does
linking dynamically (/MD) change anything? I wonder if this leads to a
condition where CRT functionality is being used before it has been
initialized -- because initialization order between the CRT and libprotobuf
would not be
this
week.
On Mon, May 4, 2009 at 9:45 AM, Peter K. koots...@gmail.com wrote:
Hi Kenton,
Thanks for the quick response.
On May 4, 12:07 pm, Kenton Varda ken...@google.com wrote:
Are you, like Fedor, linking to the CRT statically (/MT)? If so, does
linking dynamically (/MD) change anything
On Mon, May 4, 2009 at 11:12 AM, Peter K. koots...@gmail.com wrote:
OK, there seems to be projects called gtest and gtest_main that
are in the solution file, but don't seem to be in the repo.
Oh yeah, you're expected to run autogen.sh to get that, but I guess that's
hard on Windows unless you
, point is you don't need cygwin unless you want to build the protobuf
tests from SVN.
On Mon, May 4, 2009 at 5:46 PM, Peter K. koots...@gmail.com wrote:
On May 4, 7:57 pm, Kenton Varda ken...@google.com wrote:
On Mon, May 4, 2009 at 11:12 AM, Peter K. koots...@gmail.com wrote:
OK, there seems
The incoming request has to somehow specify what method it is trying to
call. Then you can do:
const MethodDescriptor* method =
service-GetDescriptor()-FindMethodByName(method_name);
if (method == NULL) {
// no such method
} else {
Message* request =
On Wed, Apr 29, 2009 at 1:14 PM, burtonator burtona...@gmail.com wrote:
I have a few thoughts after looking at the generated Java source.
No particular order...
- why does the class have to be final? I can see one wanting to have
business logic (or data type manipulation logic) that
that on my first
readthrough and was using MergeFrom, which I would guess is a tad
slower.)
-Daniel
On Tue, Apr 28, 2009 at 12:58 AM, Kenton Varda ken...@google.com wrote:
On Mon, Apr 27, 2009 at 8:38 PM, Dan danle...@gmail.com wrote:
Hello,
I've recently started using Google
environments. Do you know how big the performance penalty
is for using array-based InputStream in protobuf context?
Thanks,
Yegor
On Apr 24, 9:01 pm, Kenton Varda ken...@google.com wrote:
Hi all,
I just updated SVN (rev 120) with a large bundle of changes recently made
to
our internal copy
On Mon, Apr 27, 2009 at 8:38 PM, Dan danle...@gmail.com wrote:
Hello,
I've recently started using Google Protocol Buffers with Python on my
server. I'm writing code to convert my data source into a binary
payload, but I'm running into some snags and was wondering if there
was a better way
It appears as if your make is not properly expanding the $^ variable -- it's
replacing it with the empty string. Try using gmake?
On Thu, Apr 23, 2009 at 8:22 AM, tim.es...@gmail.com wrote:
Hi,
I am trying to build protobuf 2.0.3 on FreeBSD 7.1 and am running into
an error in the make
You're specifically talking about the Java implementation. We quite
intentionally chose to make message objects completely immutable. Version 1
of protocol buffers (never released publicly) used mutable objects, and we
found it lead to many bugs as people would modify messages that were
Petar, can you review this?
Christian: Thanks, I don't think we had any idea this was happening (doh).
Can you sign the CLA if you haven't already?
http://code.google.com/legal/individual-cla-v1.0.html -- If you own the
copyright on your patch.
On Mon, Apr 20, 2009 at 8:51 PM, Wink Saville w...@google.com wrote:
I assume the wire format for all variations of protobuf
are compatible of course there are no guarantees.
Yes, they are definitely compatible.
In my little test program I'm using both and see that
they are generating
The protocol buffers implementation was designed to run on beefy server
machines where we regularly run binaries with hundreds of megs of code and
don't worry about it that much.
Optimizing for code size does make the code a lot slower, true, but this is
compared to an insanely fast base. It's
There is no central repository of descriptors in Java. It wouldn't really
work because Java normally does not load classes until they are first used,
so the descriptors wouldn't appear in the repository until you manually
loaded the classes somehow.
Instead, you should just create a MapString,
This is suggested from time to time. The problem is that validating
messages is an arbitrarily complex operation, and the only complete
solution to this problem would involve defining an entire turing-complete
functional programming language which you could use to specify validation
constraints.
SerializeTo*() only aborts if required fields are missing. You can protect
yourself against this problem in any of the following ways:
* Compile your release builds with NDEBUG defined. The check will then be
skipped in release builds, and the message will be written even if some
required fields
.
As for the explicit initialization I humbly disagree but I understand
your point completely. Maybe someday there will be another
initialization issue that isn't as easily solved and it can be revisited.
-- Wink
On Wed, Apr 15, 2009 at 12:25 PM, Kenton Varda ken...@google.com wrote:
On Tue, Apr
We will absolutely maintain backwards-compatability of the wire format in
future versions. A version of protocol buffers that wasn't backwards
compatible would be thoroughly useless.
However, our idea of compatibility means that newer versions of the code
can successfully parse messages produced
of an explicit initialization as a long term solution
where
all ordering issues are controlled. Your thoughts on this?
To me it sounds like a lot of work without very much benefit.
On Tue, Apr 14, 2009 at 10:29 AM, Kenton Varda ken...@google.com wrote:
I think you could just do something
The descriptor itself contains a list of all of the defined fields for the
type. E.g.:
const Descriptor* type = message-GetDescriptor();
for (int i = 0; i type-field_count(); i++) {
const FieldDescriptor* field = type-field(i);
// handle field
}
On Tue, Apr 14, 2009 at 6:09 PM,
anything else?
On Wed, Apr 8, 2009 at 2:59 PM, Kenton Varda ken...@google.com wrote:
Although I see the decsriptor.cc part isn't meant to be submitted...
On Wed, Apr 8, 2009 at 2:59 PM, Kenton Varda ken...@google.com wrote:
You can use svn diff to produce a single patch file that contains
this but is non-portable, hence the different implementation in the
open source release.) If you want to update your patch, go ahead, otherwise
I'll take care of implementing this when it gets to the top of the queue.
:)
On Mon, Apr 13, 2009 at 5:21 PM, Kenton Varda ken...@google.com wrote:
My
Thanks for doing this! Can you send it to me as a code review via
codereview.appspot.com? Also, you'll need to sign the CLA if you haven't
already:
http://code.google.com/legal/individual-cla-v1.0.html -- If you own
copyright on your work.
http://code.google.com/legal/corporate-cla-v1.0.html --
On Fri, Apr 10, 2009 at 5:24 AM, Alexander Philippou
alexander.philip...@gmail.com wrote:
The redundancy elimination mechanism of FI is actually a vocabulary
and it works differently than compression algorithms do.
I think we define compression differently. In my book, redundancy
Using wget (a unix command -- available on Windows using Cygwin), you can
download the whole site like so:
wget -r -l inf -np -p -k
http://code.google.com/apis/protocolbuffers/index.html
Options:
-r = Recursive
-l inf = Infinite recursion depth
-np = Don't follow links to parent directories
-p =
On Tue, Apr 7, 2009 at 10:15 PM, ShirishKul shirish...@gmail.com wrote:
I do not have any sample file to share with you. But I think FI
handles the repeatative attribute-values.
OK, well, I call that compression. Try gzipping the final protobuf and FI
documents and comparing the compressed
pm, Kenton Varda ken...@google.com wrote:
It appears you are not linking against libprotobuf.lib.
On Wed, Apr 8, 2009 at 8:28 AM, scotty2...@gmail.com wrote:
I think part of my problem was using precompiled headers in the
project. I've removed that option and recreated my project, but I
Although I see the decsriptor.cc part isn't meant to be submitted...
On Wed, Apr 8, 2009 at 2:59 PM, Kenton Varda ken...@google.com wrote:
You can use svn diff to produce a single patch file that contains both
parts of this change.
On Tue, Apr 7, 2009 at 10:01 PM, Wink Saville w
was, but it's working
now.
On Apr 8, 4:10 pm, Kenton Varda ken...@google.com wrote:
On Wed, Apr 8, 2009 at 2:01 PM, scotty2...@gmail.com wrote:
I don't know how else to link to libprotobuf.lib. Here's the resulting
command lines of the options I've tried:
/LIBPATH :C:\Development
Currently there is no support for wstring. Instead, strings are represented
by STL string objects using UTF-8 encoding for Unicode characters.
On Sat, Apr 4, 2009 at 4:52 AM, nenad_le...@yahoo.com wrote:
Hi,
protocols buffers look very nice, taking into account that could be
used on
If you implemented this in ConsumeInteger(), it would not follow the usual
symbol lookup semantics used everywhere else in the language. For example,
you would not be able to refer to enums defined later in the file, or
defined in a different file. You might be able to handle enums defined
More specifically, you need to make sure that you use the same import path
for all of the .proto files in your package. The easiest thing to do is to
compile everything from the same top-level directory (and this is good style
anyway -- recursive Makefiles can cause lots of problems). Another
What are the errors?
On Tue, Apr 7, 2009 at 3:58 PM, scotty2...@gmail.com wrote:
I am trying to get started using pb, but I am stuck. I've got my
messages compiled into their .h and .cc parts, i've added those to my
project. I built protobuf in vs 2009, and I've added the
protobuf-2.0.3\src
You can easily implement your own text format by writing code based on
protobuf reflection. In fact, the official TextFormat class is based on
reflection. So take a look at the code for the TextFormat class and write
something like that with whatever modifications you need.
On Fri, Apr 3, 2009
On Fri, Apr 3, 2009 at 2:40 AM, ShirishKul shirish...@gmail.com wrote:
I found that for a typical data to be transferred across the wire for
size of 500KB that a XML file would represent has corresponding file
size as 300KB for PB binary and around 130KB for XML Fast Infoset
binary file.
No, the newlines are part of the binary data. (They aren't really
newlines though since the data is not text. They are bytes with the value
10.)
Or are you actually talking about the text format?
On Thu, Apr 2, 2009 at 3:02 AM, ShirishKul shirish...@gmail.com wrote:
In the binary file
Most Unix-like platforms (Linux, Mac OSX, FreeBSD, Solaris, Cygwin, etc.)
and Windows (MinGW, MSVC) are supported. libprotobuf does not use many
OS-specific features so it's likely to be easy to port to other platforms.
However, it is not well-designed for stripped-down embedded systems with
Concatenating encoded protocol messages has the effect of merging them, with
the same semantics as the MergeFrom() method. That is, repeated fields will
be concatenated, singular primitive fields will take the *last* value, and
singular embedded messages/groups will be merged.
In your case, your
On Wed, Apr 1, 2009 at 2:04 PM, le lance.earw...@gmail.com wrote:
Thanks for the reply. I think I understand what is happening here but
have an additional question.
You stated three rules. When you say ...singular embedded messages/
groups will be merged., does that imply that the other
:
Fair enough. I've attached a patch that adds a new command line option.
Oleg.
On Thu, Mar 26, 2009 at 9:14 AM, Kenton Varda ken...@google.com wrote:
The existing format mimics GCC. Unfortunately I think if we changed it,
it
would break other tools. Maybe we could enable this format based
files are attached
Best
On Mon, Mar 30, 2009 at 12:14 PM, Kenton Varda ken...@google.com wrote:
What does your .proto file look like? And the code that uses it?
On Sun, Mar 29, 2009 at 9:06 PM, Yingfeng yingfeng.zh...@gmail.comwrote:
Hi,
We are looking for a fast mechanism
vectorint of
size 1000 !
Best
On Tue, Mar 31, 2009 at 2:07 AM, Kenton Varda ken...@google.com wrote:
Several points:
* Some of your test cases seem to be parsing from or serializing to files.
This may be measuring file I/O performance more than it is measuring the
respective
for boost to serialize vectorint of size 1000 !
It takes 0.05 seconds for boost to deserialize vectorint of size 1000
!
Best
On Tue, Mar 31, 2009 at 10:46 AM, Kenton Varda ken...@google.com wrote:
That's more like it. :)
On Mon, Mar 30, 2009 at 7:09 PM, Yingfeng Zhang
What does your .proto file look like? And the code that uses it?
On Sun, Mar 29, 2009 at 9:06 PM, Yingfeng yingfeng.zh...@gmail.com wrote:
Hi,
We are looking for a fast mechanism for serialization/deserialization.
Here is our comparison between pb and boost:
We hope to
On Fri, Mar 27, 2009 at 3:33 AM, Jesper Eskilson jes...@eskilson.se wrote:
(BTW: I created a set of CMake (http://cmake.org) build files for
Protobufs, in case you're interested in not maintaining parallell
Makefiles/project files for Linux/Windows.)
We considered using cmake originally, but
You could treat the protobuf classes as private implemnetation helpers.
Your public interface would have methods like you describe, and internally
they'd just copy the object's state into a protocol buffer and then
serialize it.
On Fri, Mar 27, 2009 at 2:32 AM, Paul Runyan
The existing format mimics GCC. Unfortunately I think if we changed it, it
would break other tools. Maybe we could enable this format based on a
command-line flag?
On Wed, Mar 25, 2009 at 8:59 PM, os_ oleg.smol...@gmail.com wrote:
Hey there, below is a tiny patch that lets VS200x go to the
Did you make sure to compile libprotobuf and your code using the same
settings? (E.g. debug vs. release, same compiler version.) MSVC is pretty
touchy about that when using STL in the interface to a library.
On Thu, Mar 26, 2009 at 9:08 AM, jesper.eskil...@gmail.com wrote:
I have
There are a few AS ports listed here:
http://code.google.com/p/protobuf/wiki/OtherLanguages
I don't know how well any of them work.
On Thu, Mar 26, 2009 at 2:03 AM, Ayr w2m...@gmail.com wrote:
I want to use Protocol Buffers in my Flex project.
Is that possible?
On Thu, Mar 26, 2009 at 9:28 AM, Jesper jesper.eskil...@gmail.com wrote:
I think so, but I'll double-check. (Wouldn't that have showed up when
libprotobuf.lib was linked into the exe?)
Unfortunately, probably not. Strange crashes at runtime are the usual
symptom. :(
You can see a list of the stuff that's already in SVN by looking at
CHANGES.txt:
http://code.google.com/p/protobuf/source/browse/trunk/CHANGES.txt
It will probably just be another incremental update, nothing terribly
significant.
Pushing another release is high on my todo list, but somehow I've
On Mon, Mar 23, 2009 at 1:38 AM, ode fuji...@gmail.com wrote:
There is api in c++, ParseFromIstream, but is there any similar api in
python?
No, there's no Python equivalent right now.
But, the parsed objects are bigger than the original serialized data, so if
the original serialized data
Protocol Buffers is licensed under the new BSD license. The license info is
mentioned on the sidebar of the main project page:
http://code.google.com/p/protobuf/
It is also found in the file COPYING.txt in the distribution:
http://protobuf.googlecode.com/svn/trunk/COPYING.txt
On Mon, Mar 23,
Well, note that if you compile with -DNDEBUG, the abort won't happen. We
have a no-exception policy in C++, so I don't think we can replace this with
an exception. Is -DNDEBUG good enough for you or do you want to look for
another solution?
On Mon, Mar 23, 2009 at 2:32 PM, Dave Bailey
23, 2:50 pm, Kenton Varda ken...@google.com wrote:
Well, note that if you compile with -DNDEBUG, the abort won't happen. We
have a no-exception policy in C++, so I don't think we can replace this
with
an exception. Is -DNDEBUG good enough for you or do you want to look for
another
files, but instead use
the DynamicMessage to get values out of a protobuf stream.
Cheers,
Shay
On Mar 23, 11:47 pm, Kenton Varda ken...@google.com wrote:
I'm a little confused by your message. You say you have the .proto
files,
but you don't know the types? But don't the .proto files
If you changed all the string types to bytes instead, then you should
not see that error. Are you sure you did that? If so, can you write a
small demo program which produces this error, even when the protobuf type
contains no string fields, and send it to me?
On Fri, Mar 20, 2009 at 11:16 AM,
The existing Java implementation is probably too heavyweight for J2ME.
Sorry.
The encoding is documented here:
http://code.google.com/apis/protocolbuffers/docs/encoding.html
Is this a Google service you want to talk to? If so, are you working with
one of the Google mobile teams at all? They
On Wed, Mar 18, 2009 at 11:23 PM, ShirishKul shirish...@gmail.com wrote:
Output in my case is a file to which i'm writing.
But again, this doesn't seem to be matching with what your throughput
is. Do I still need to make changes to seek more optimum results?
What happens if you serialize to
On Wed, Mar 18, 2009 at 8:31 AM, sauternes hossein.gho...@gmail.com wrote:
I've read the various useful posts on this discussion group about
using popLimit() and pushLimit() to control how many bytes are read at
a time when using a CodedInputStream, but is there an elegant way of
detecting
First, are you using:
option optimize_for = SPEED;
? If not, add that line to your .proto file. But even without that option,
the speed shouldn't be that slow. Maybe you can run in a profiler to see
what's taking so long?
Are you writing to an in-memory buffer or some sort of output stream?
parseFrom() reads and parses the entire stream, so it won't stop reading
until it reaches EOF. If you don't want to close the socket on the sending
end, then you should write the size of the message first, then the contents.
Then, on the receiving end, you'll need to read that size first, then
I'm guessing this question is about protobuf-net, specifically? (Not sure
since I haven't used it myself.)
On Thu, Mar 12, 2009 at 5:23 AM, Bryan bryanbass...@gmail.com wrote:
I noticed in my test app, and then in the ProtoBuf source, that the
serialization of Nullable properties ignores the
It's not possible to set values by writing directly into a byte array since
the size of a value depends on its contents. For example, integers are
encoded using the varint encoding which uses fewer bytes for smaller
numbers. So, if the value of a particular int32 field is 1, and then you
set it
*not* know when the end has been reached if you
don't do this. The protocol buffer format is *not* self-delimiting -- it
assumes that whatever container it is embedded in will keep track of the
length.
Is there any solution that is a bit more elegant?
On Mar 12, 10:12 pm, Kenton Varda ken
, Mar 10, 2009 at 3:35 PM, Scott Stafford scott.staff...@gmail.comwrote:
Are you interested in a patch from me to add them or would you just
add it yourselves at some point?
On Mar 9, 2:53 pm, Kenton Varda ken...@google.com wrote:
It wasn't added because the reflection interface is already
If you are OK with the possibility that future versions of protocol buffers
may break your code (probably in minor ways), then you can do whatever you
want. If you aren't OK with that, then you should not subclass protocol
buffer types. There are tons of ways that future changes to the
801 - 900 of 1054 matches
Mail list logo
