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
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()
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
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
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
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
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
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:
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,
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:
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 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
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
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:
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
;
getNeighborsResponse.Clear();
currentBatchSize = 0;
}
On Jul 14, 1:27 am, Kenton Varda ken...@google.com wrote:
Oh, I didn't even know you were including composition in there. My
benchmarks are only
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
Did you make sure to compile your debug build against a debug build of
libprotobuf? MSVC fails miserably when trying to mix and match debug vs.
release, apparently because the STL classes have different representations
between the two.
On Wed, Jul 15, 2009 at 7:38 AM, Mr Moose
On Wed, Jul 15, 2009 at 10:56 AM, jasonh jas...@google.com wrote:
Foo f = Foo.newBuilder().mergeFrom(...).setCookie(newCookieVal).build
();
There's actually a shortcut for this: the toBuilder() method of the Message
interface returns a Builder that is pre-initialized as a copy of that
Hmm, probably GzipOutputStream is not setting the same compression
parameters as gzip itself uses by default. I'm happy to accept a patch
fixing this. Does the interface (to GzipOutputStream) currently have a way
to control compression parameters? If not, it probably should.
On Wed, Jul 15,
Hi all,
I will be on vacation and not checking e-mail through July 22nd. I've asked
fellow protobuf dev Jason to help answer questions in the meantime, but if
you see a question that isn't answered and you know the answer, please feel
free to jump in. (That goes for when I'm not on vacation,
--
*From:* Kenton Varda [mailto:ken...@google.com]
*Sent:* Tuesday, July 14, 2009 3:26 AM
*To:* Alex Black
*Cc:* Protocol Buffers
*Subject:* Re: Performance: Sending a message with ~150k items, approx
3.3mb, can I do better than 100ms?
OK. If your message composition (or parsing
On Fri, Jul 17, 2009 at 8:13 PM, Alex Black a...@alexblack.ca wrote:
When I write out messages using C++ I'm careful to clear messages and
re-use them, is there something equivalent on the java side when
reading those same messages in?
No. Sorry. This just doesn't fit at all with the Java
inputs on this one.
Thanks Regards,
Vikram
On Jul 14, 6:35 pm, Kenton Varda ken...@google.com wrote:
It looks like your implementation of hash_map is not working correctly --
all lookups are failing. You might try writing a little test for
hash_map
itself that would be easier to debug
On Thu, Jul 23, 2009 at 12:32 AM, alopecoid alopec...@gmail.com wrote:
Hi,
I haven't actually used the Java protobuf API, but it seems to me from
the quick occasional glance that this isn't entirely true. I mean,
specifically in response to the code snippet posted in the original
message,
On Thu, Jul 23, 2009 at 7:15 PM, alopecoid alopec...@gmail.com wrote:
Hmm... that strikes me as strange. I understand that the Message
objects are immutable, but the Builders are as well? I thought that
they would work more along the lines of String and StringBuilder,
where String is
How annoying. I'll make sure this or something like it gets into the next
release -- which I'm going to try to push next week.
On Wed, Jul 22, 2009 at 8:36 AM, anonymous eric.pe...@hp.com wrote:
Hello,
I was not able to compile a Java file generated by protoc 2.10 from a
rather big .proto
That implementation was written completely independently of the protocol
buffers team at google, and is not maintained by us. I've heard that it is
buggy, and it doesn't support many of the newer language features, though
since I've never used it myself or looked at the code I'm not sure if
What compiler flags are you using? It looks like you have an excessively
pedantic warning mode enabled, with -Werror to make warnings into errors,
and it is applying even to system headers (usually warnings in system
headers aren't reported).
On Mon, Jul 27, 2009 at 6:27 PM, achap
, but I am using -W -pedantic, which
apparently is the problem.
what is the likely hood that this will work with the pedantic warning
enabled? My build system forces pendant... I can override it, but I'd
rather not if I don't have too.
Thanks.
On Jul 27, 6:39 pm, Kenton Varda ken
I just committed the new lite mode refactoring for C++ and Java to SVN.
To use the new feature, add this line to your .proto file:
option optimize_for = LITE_RUNTIME;
This will cause protoc to generate code which is just as fast as with
optimize_for = SPEED, but lacks descriptors, reflection,
In C++, you can use the standard STL sort() function:
http://www.sgi.com/tech/stl/sort.html
http://www.sgi.com/tech/stl/sort.htmlRepeatedPtrField supports iterators,
so you can do something like:
#include algorithm
struct StudentOrdering {
inline operator()(const Student* a, const
re-run make
install) then everything should be good.
thanks
On Wed, Jul 29, 2009 at 2:22 PM, Kenton Varda ken...@google.com wrote:
On Wed, Jul 29, 2009 at 4:14 AM, Sushil Shelly skshe...@gmail.comwrote:
I need to upgrade a linux installation of protocol buffers. I have 2.0.3
and need
On Wed, Jul 29, 2009 at 11:49 AM, Monty Taylor mord...@inaugust.com wrote:
A little off-topic - but do you have a cutoff date for patches to get in
to that? I've still got some Sun Studio issues I've been working on a
patch for that I'd love to be in 2.2.0...
There's no official schedule, so
On Wed, Jul 29, 2009 at 11:56 AM, Javier espinosa.javie...@gmail.comwrote:
Warning: This system can not link to static lib archive
libprotobuf.la. i have the capability to make that librar
automatically link in when you link to this library. But I cna only do
htis if you have a shared versino
Probably you are treating the bytes as a NUL-terminated string somewhere,
and so the message is being cut short at the zero. Protocol messages can
contain NUL (zero-value) bytes, so you cannot pass an encoded protocol
message as a plain char* -- you must keep track of the size.
On Wed, Jul 29,
Also, in all likelihood the ParseFrom*() call is failing, but you aren't
checking the return value.
On Wed, Jul 29, 2009 at 4:54 PM, Kenton Varda ken...@google.com wrote:
Probably you are treating the bytes as a NUL-terminated string somewhere,
and so the message is being cut short at the zero
The Builder interface has a method setField() which takes a FieldDescriptor
and a value. You can pass the FieldDescriptor for an extension to set an
extension, and pass the message object as the value. You can get the
FieldDescriptor from ExtensionRegistry or from
On Wed, Jul 29, 2009 at 6:34 PM, Jeff Bailey jeffbai...@google.com wrote:
*sigh* It looks like the version at appspot.com isn't GA+ enabled, so I
sign in and it thinks I'm not signed in.
Anyhow, a few comments:
Since it's generated by configure.ac, do you need it in bin_SCRIPTS? I
think
(New patch set uploaded.)
On Thu, Jul 30, 2009 at 8:59 AM, Kenton Varda ken...@google.com wrote:
On Wed, Jul 29, 2009 at 6:34 PM, Jeff Bailey jeffbai...@google.comwrote:
*sigh* It looks like the version at appspot.com isn't GA+ enabled, so I
sign in and it thinks I'm not signed
In other words, the scoping semantics are just like C++ namespaces, but we
use . rather than :: as the scope separator.
On Thu, Jul 30, 2009 at 1:50 AM, Constantinos Michael
cmmich...@gmail.comwrote:
Try doing this:
message foo {
message X { }
message bar {
message X { }
to execute
them and fails. I have also tried to find out what make Error 127
means but I still haven't had any luck with that. And to think I did
all of this on my Mac on the first try *sigh...
On Jul 30, 10:14 am, Kenton Varda ken...@google.com wrote:
I don't see an actual error message
as part of their own configure script.
Provide an example with PKG_CONFIG or something like that.
Otherwise, looks good. Thanks!
Jeff Bailey | Google, Inc. | +1 514 670-8754
On Thu, Jul 30, 2009 at 12:00 PM, Kenton Varda ken...@google.com wrote:
(New patch set uploaded.)
On Thu, Jul 30
I need a lot more information to even begin speculating about this, such as
what language you are using and any error messages that were printed when it
crashed. A stack trace would also be nice.
On Thu, Jul 30, 2009 at 9:46 AM, muka ly.pas...@gmail.com wrote:
Hi,
I have a problem with the
On Thu, Jul 30, 2009 at 12:12 PM, Kenton Varda ken...@google.com wrote:
Yeargh, I'm behind the times. pkg-config? I guess I should be
integrating with that rather than writing my own script?
On Thu, Jul 30, 2009 at 9:05 AM, Jeff Bailey jeffbai...@google.comwrote:
lgtm
42 Packages which
On Wed, Jul 29, 2009 at 3:41 PM, ijuma ism...@juma.me.uk wrote:
Is there a way to disable this behaviour? As you say, it doesn't seem
particularly useful for sophisticated JVMs and unless I am missing
something, the queue is currently unbounded so it could end up
retaining quite a bit of
Yeah, the test only compares default compression to no compression --
even with the small message, default compression manages to compress a
little bit.
Committed as rev 170.
On Fri, Jul 31, 2009 at 5:08 PM, peter.k...@gmail.com wrote:
On 2009/07/31 23:56:40, kenton wrote:
This looks great,
I think text relocation has something to do with the way a dynamic library
is compiled and/or loaded. This is not something which Protocol Buffers
asks for specifically -- either libtool, your linker, or your binary loader
chose to use this feature without being asked for it. It seems that
On Sat, Aug 1, 2009 at 4:42 AM, Jon Skeet sk...@pobox.com wrote:
Out of interest Kenton, does this make the bootstrapping code simpler?
I'd imagine that can be built with just a lite version. It would be
nice to get rid of some of the nastiness that's involved in C# just to
get the
Protocol message classes can only contain other protocol message classes,
not arbitrary Java classes. Otherwise, what would happen when you compile
the same .proto file in C++ or another language?
On Mon, Aug 3, 2009 at 1:14 PM, Tai maitai.tru...@gmail.com wrote:
Hi,
I guess this is a
(java.io.ObjectInputStream in)
throws ClassNotFoundException, IOException {
MyClassMessage.MyClass message =
MyClassMessage.MyClass.parseFrom(in);
anotherClassName= Class.forName(message.getAnotherClassName
());
}
On 3 Aug., 23:06, Kenton Varda ken...@google.com
Your approach actually won't work (at least, as you've written the code)
because if you write two messages to a stream without any sort of delimiter,
it's impossible to figure out later where one message ends and the other
starts.
But I suggest doing this instead:
message A {
...
}
message B {
In Java I introduced methods called writeDelimitedTo(),
parseDelimitedFrom(), and mergeDelimitedFrom() in version 2.1.0. These read
and write messages which are prefixed with the message size, thus allowing
multiple messages to be written to one stream without any external
delimiter. As one or
What were you searching for? Are you sure there should be results?
On Tue, Aug 4, 2009 at 3:07 PM, yellen yel...@gmail.com wrote:
I'm finding that the search function provided by the group is
returning much less than I expect. Is anyone else having similar
trouble?
spaces are accepted when
doing a file lookup. I further assume when protoc takes the argument
it uses the filename including the white space to generate the class
name. Maybe that was the reason why the class was called
MyClassProto and not MyClass.
Tai
On 4 Aug., 23:19, Kenton Varda ken
Interesting. I'll file a bug against google groups.
On Tue, Aug 4, 2009 at 3:25 PM, Adam yel...@gmail.com wrote:
On Aug 4, 5:16 pm, Kenton Varda ken...@google.com wrote:
What were you searching for? Are you sure there should be results?
I originally searched for 'rpc' which I'm pretty
Can you just have the OParameter message contain optional fields of type
string and int64, where only one of the two is ever set? Then don't have
specific types corresponding to OStringParameter and OLongParameter.
On Tue, Aug 4, 2009 at 5:07 PM, Tai maitai.tru...@gmail.com wrote:
Hi,
I
different member names.
Tai
On 5 Aug., 03:05, Kenton Varda ken...@google.com wrote:
Can you just have the OParameter message contain optional fields of type
string and int64, where only one of the two is ever set? Then don't have
specific types corresponding to OStringParameter
Sorry, they are not implemented, but feel free to submit a patch.
On Wed, Aug 5, 2009 at 6:13 AM, jacobgladish jacob.glad...@sig.com wrote:
Does anyone know the current state of custom options with python? Are
they functional?
--~--~-~--~~~---~--~~
You
Currently there's no way to do that. You could add an option to
descriptor.proto, and update the Java code generator to honor it. Or you
could just use a postprocessing step like:
sed -i 's/^public class/class/' MyProto.java
On Wed, Aug 5, 2009 at 6:41 AM, v6ak vit...@gmail.com wrote:
How
Protobuf 2.1.0 throws NPE when you try to set a field to null. So, this has
been long fixed.
On Fri, Aug 7, 2009 at 4:30 AM, Brice Figureau
brice...@daysofwonder.combrice%2...@daysofwonder.com
wrote:
Hi,
Oops, sorry, I was plain wrong.
It turns out the code was setting the nonce parameter
The groups people are working on fixing this.
On Fri, Aug 7, 2009 at 12:51 PM, Scott Stafford scott.staff...@gmail.comwrote:
I'm having zero results too, searching for DescriptorPool for
instance.
On Aug 4, 7:54 pm, Kenton Varda ken...@google.com wrote:
Interesting. I'll file a bug
301 - 400 of 1054 matches
Mail list logo
