optimize_for = LITE_RUNTIME and DebugString() / ShortDebugString()
While experimenting with LITE_RUNTIME I noticed that the C++ methods
DebugString() and ShortDebugString() are only present on Message, not
MessageLite.
I understand that DebugString()/ShortDebugString() are implemented via
reflection, which isn't available in the lite runtime, but what about a
simple implementation that returns a less detailed string? It seems
reasonable that you'd get less useful debug output when using the lite
runtime. Something like this perhaps:
string MessageLite::ShortDebugString() const {
string result;
result += (lite message type ;
result += GetTypeName();
result += );
return result;
}
That would mean you wouldn't need to do so much conditional compilation
for code that can be built against either the full or lite library. I
have a fair amount of code of the form:
DEBUG(CONNECTION, Send: %s, message.ShortDebugString().c_str());
and wrapping it all in #ifdefs is fairly awkward.
-O
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: Additional language
The problem is the root certificate (CA Cert Signing Authority) - it certainly isn't in my trusted set of root certificates... On Aug 19, 3:50 am, opticron nyphb...@gmail.com wrote: It is a CACert certificate that is valid until May of 2010. On Aug 18, 7:46 pm, Kenton Varda ken...@google.com wrote: I'd like to add this to the list, but I noticed that the wiki page is an HTTPS link to a site with an invalid SSL certificate. I tried to change the protocol to just HTTP but the site automatically redirects to HTTPS. Modern browsers complain very loudly about this, and I feel weird posting a link that's going to display a big red security warning. Can you maybe fix your server to allow regular HTTP connections? On Tue, Aug 18, 2009 at 5:25 AM, opticron nyphb...@gmail.com wrote: I have spent some time developing a protocol buffer compiler in the D language. The wiki page is located at https://256.makerslocal.org/ wiki/index.php/ProtocolBuffer and the SVN repository that contains the compiler is located at http://opticron.no-ip.org/svn/branches/ PBCompiler. Please, note that you'll actually have to check out the branch, since the backend library it uses is in a svn:externals reference to a different location in the same repository. The compiler itself needs some work, but the generated code seems to generate and parse byte strings correctly. Please add my project to your third party compilers page. Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Installation requirements and supported platforms?
Thanks for your answers! Just another ``trivial´´ question: Let's assume that I've installed Protocol Buffers on my Windows(tm) machine so that I'm able to generate language-specific stubs. I could transfer them to the target system runnnig Solaris. Do the stubs still depend on a protocol buffers runtime? I guess yes, but maybe this kind of stuff is managed thoroughly through native means offered by the operating systems (?). What I am primarily interested are bindings for Java and Perl. Thanks Greg --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Additional language
What certificate authorities would be acceptable for this purpose? I see that Chrome has root certs for only verisign and thawte, but that's still in beta and can hardly be considered a realistic sampling. The Mozilla project has root certs for MANY more than that. On Aug 19, 2:41 am, Marc Gravell marc.grav...@gmail.com wrote: The problem is the root certificate (CA Cert Signing Authority) - it certainly isn't in my trusted set of root certificates... On Aug 19, 3:50 am, opticron nyphb...@gmail.com wrote: It is a CACert certificate that is valid until May of 2010. On Aug 18, 7:46 pm, Kenton Varda ken...@google.com wrote: I'd like to add this to the list, but I noticed that the wiki page is an HTTPS link to a site with an invalid SSL certificate. I tried to change the protocol to just HTTP but the site automatically redirects to HTTPS. Modern browsers complain very loudly about this, and I feel weird posting a link that's going to display a big red security warning. Can you maybe fix your server to allow regular HTTP connections? On Tue, Aug 18, 2009 at 5:25 AM, opticron nyphb...@gmail.com wrote: I have spent some time developing a protocol buffer compiler in the D language. The wiki page is located at https://256.makerslocal.org/ wiki/index.php/ProtocolBuffer and the SVN repository that contains the compiler is located at http://opticron.no-ip.org/svn/branches/ PBCompiler. Please, note that you'll actually have to check out the branch, since the backend library it uses is in a svn:externals reference to a different location in the same repository. The compiler itself needs some work, but the generated code seems to generate and parse byte strings correctly. Please add my project to your third party compilers page. Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: RPM Spec File
On Wed, Aug 19, 2009 at 02:19, Kenton Vardaken...@google.com wrote: The problem with these spec files is that they're large and complicated and I just don't have time to learn how they work and maintain them. If someone would like to commit to maintaining these things -- which means I'd call on you to update them for each release, answer questions about them, etc., and I'd need you to respond promptly (within a day or two) -- then we could add them to the official package. Otherwise I'd prefer to stick with the current decentralized approach. I think you are right regarding spec file management: maintaining a generic spec that work for each RPM-based distribution is a lot of work. These files became a big mess really fast: think about supporting different distributions, distribution versions and architectures... That's a lot of possible combination ! I understand why you require such commitment and I agree with you. So +1 for the decentralized approach. BTW, should we continue packaging-related discussion of protobuf here ? BTW, Kevin, I'm confused about this line in your changelog: - Add -lpthread option to environment (else configure set it to -pthread) -pthread is the correct option, and it implies -lpthread. -pthread ensures that the C runtime library uses thread-safe functions (e.g. errno becomes thread-local) whereas -lpthread merely links against libpthread.so. Why did you change this? Here is what happened when I don't force the -lpthread option. First, configure guess that we should use -pthread: (...) checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... no checking whether pthreads work with -Kthread... no checking whether pthreads work with -kthread... no checking for the pthreads library -llthread... no checking whether pthreads work with -pthread... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no checking whether to check for GCC pthread/shared inconsistencies... yes checking whether -pthread is sufficient with -shared... yes checking the location of hash_map... ext/hash_map configure: creating ./config.status (...) Then the compilation fail: (...) libtool: link: x86_64-mandriva-linux-gnu-g++ -shared -nostdlib /usr/lib/gcc/x86_64-manbo-linux-gnu/4.3.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-manbo-linux-gnu/4.3.2/crtbeginS.o .libs/common.o .libs/once.o .libs/hash.o .libs/extension_set.o .libs/generated_message_util.o .libs/message_lite.o .libs/repeated_field.o .libs/wire_format_lite.o .libs/coded_stream.o .libs/zero_copy_stream.o .libs/zero_copy_stream_impl_lite.o .libs/strutil.o .libs/substitute.o .libs/structurally_valid.o .libs/descriptor.o .libs/descriptor.pb.o .libs/descriptor_database.o .libs/dynamic_message.o .libs/extension_set_heavy.o .libs/generated_message_reflection.o .libs/message.o .libs/reflection_ops.o .libs/service.o .libs/text_format.o .libs/unknown_field_set.o .libs/wire_format.o .libs/gzip_stream.o .libs/printer.o .libs/tokenizer.o .libs/zero_copy_stream_impl.o .libs/importer.o .libs/parser.o -lz -L/usr/lib/gcc/x86_64-manbo-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-manbo-linux-gnu/4.3.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-manbo-linux-gnu/4.3.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-manbo-linux-gnu/4.3.2/crtendS.o /usr/lib/gcc/x86_64-manbo-linux-gnu/4.3.2/../../../../lib64/crtn.o -pthread -Wl,--as-needed -Wl,--no-undefined -Wl,-z -Wl,relro -pthread -Wl,-soname -Wl,libprotobuf.so.4 -o .libs/libprotobuf.so.4.0.0 libtool: compile: x86_64-mandriva-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -pthread -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -MT python_generator.lo -MD -MP -MF .deps/python_generator.Tpo -c google/protobuf/compiler/python/python_generator.cc -o python_generator.o /dev/null 21 .libs/common.o: In function `InitShutdownFunctionsOnce': /home/kevin/rpm/BUILD/protobuf-2.2.0/src/./google/protobuf/stubs/once.h:115: undefined reference to `pthread_once' .libs/common.o: In function `GoogleOnceInit': /home/kevin/rpm/BUILD/protobuf-2.2.0/src/./google/protobuf/stubs/once.h:115: undefined reference to `pthread_once' .libs/common.o: In function `GoogleOnceInit': /home/kevin/rpm/BUILD/protobuf-2.2.0/src/google/protobuf/stubs/common.cc:137: undefined reference to `pthread_once' .libs/extension_set.o: In function `GoogleOnceInit': /home/kevin/rpm/BUILD/protobuf-2.2.0/src/./google/protobuf/stubs/once.h:115: undefined reference to `pthread_once' /usr/bin/ld: Dwarf Error: Offset (391001) greater than or equal to .debug_str size (366455). .libs/descriptor.o: In function `InitGeneratedPoolOnce': /home/kevin/rpm/BUILD/protobuf-2.2.0/src/./google/protobuf/stubs/once.h:115:
Re: RPM Spec File
On Wed, Aug 19, 2009 at 10:47 AM, Kevin Deldycke ke...@deldycke.com wrote: BTW, should we continue packaging-related discussion of protobuf here ? Please do. Is this issue worth a bug report ? Well, I haven't observed this problem on other platforms or distros. What happens if you write a very basic program that uses pthread_once, then try to compile it with -pthread (but not -lpthread)? If this doesn't work, I suspect something is wrong with the way GCC was built for your distribution. In any case, the work-around you may want is to set PTHREAD_CFLAGS='-pthread -lpthread' -- that is, pass both flags. Or better yet, set PTHREAD_CFLAGS=-pthread and PTHREAD_LIBS=-lpthread -- this way -lpthread is only passed while linking. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: optimize_for = LITE_RUNTIME and DebugString() / ShortDebugString()
Makes sense. I'm happy to accept a patch along these lines.
On Tue, Aug 18, 2009 at 11:12 PM, Oliver Jowett oliver.jow...@gmail.comwrote:
While experimenting with LITE_RUNTIME I noticed that the C++ methods
DebugString() and ShortDebugString() are only present on Message, not
MessageLite.
I understand that DebugString()/ShortDebugString() are implemented via
reflection, which isn't available in the lite runtime, but what about a
simple implementation that returns a less detailed string? It seems
reasonable that you'd get less useful debug output when using the lite
runtime. Something like this perhaps:
string MessageLite::ShortDebugString() const {
string result;
result += (lite message type ;
result += GetTypeName();
result += );
return result;
}
That would mean you wouldn't need to do so much conditional compilation
for code that can be built against either the full or lite library. I
have a fair amount of code of the form:
DEBUG(CONNECTION, Send: %s, message.ShortDebugString().c_str());
and wrapping it all in #ifdefs is fairly awkward.
-O
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: Building without RTTI support causes make check to hang (recursive call to pthread_once?)
Sigh. More bugs in descriptor bootstrapping, eh?
The problem is that without RTTI, MergeFrom(const Message other) cannot
tell if other is actually the exact same class as this, so it has to
fall back to reflection... but reflection does not work if descriptors
aren't available... and we're in the middle of building said descriptors at
the time. So you get a deadlock, because descriptor initialization cannot
complete until descriptor initialization completes.
The solution is to avoid calling the generic version of MergeFrom anywhere
in descriptor.cc. I'll put it on my TODO to fix this. Note that this only
matters if you use custom options -- if not you should be safe.
On Tue, Aug 18, 2009 at 8:42 PM, Oliver Jowett oliver.jow...@gmail.comwrote:
Oliver Jowett wrote:
#4 0x2b85e3ffb67a in
google::protobuf::internal::ReflectionOps::Merge (fr...@0x262e320,
to=0x268f0e0) at ./google/protobuf/message.h:311
#5 0x0071dc4a in protobuf_unittest::ComplexOpt6::MergeFrom
(this=0x268f0e0, fr...@0x262e320) at google/protobuf/
unittest_custom_options.pb.cc:3753
#6 0x2b85e3fa844e in
google::protobuf::internal::ExtensionSet::MergeFrom (this=0x268f048,
other=value optimized out) at google/protobuf/extension_set.cc:644
#7 0x2b85e3fdf191 in google::protobuf::MessageOptions::MergeFrom
(this=0x268f040, fr...@0x268a530) at google/protobuf/descriptor.pb.cc:4732
The difference in behaviour is in this bit of generated code:
void MessageOptions::MergeFrom(const ::google::protobuf::Message from)
{
Sorry, wrong bit of code. The MessageOptions::MergeFrom in the
stacktrace is actually the const MessageOptions from variant. It
looks like it's actually ComplexOpt6::MergeFrom that differs in
behaviour with RTTI off.
-O
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: Installation requirements and supported platforms?
The source code generated by protoc is identical regardless of what platform protoc itself is executed on. The runtime library is always required. The Java code (and the Python code, and probably Perl too though that's a third-party implementation) is completely platform-neutral so it should work on every platform regardless of where you compile it. On Wed, Aug 19, 2009 at 2:05 AM, Gregor Stich grgs...@googlemail.comwrote: Thanks for your answers! Just another ``trivial´´ question: Let's assume that I've installed Protocol Buffers on my Windows(tm) machine so that I'm able to generate language-specific stubs. I could transfer them to the target system runnnig Solaris. Do the stubs still depend on a protocol buffers runtime? I guess yes, but maybe this kind of stuff is managed thoroughly through native means offered by the operating systems (?). What I am primarily interested are bindings for Java and Perl. Thanks Greg --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Any protocol buffers MIME types?
Nope, there hasn't been any off-list discussion. Personally I have no opinion on the matter since it doesn't affect anything that I do with protocol buffers. However, the Google Wave people -- who are developing an open-source protocol that will use protocol buffers -- seem to care about this and might be submitting an official registration. You might talk to them about it. http://www.waveprotocol.org/ On Mon, Aug 17, 2009 at 10:01 PM, M. David Peterson xmlhac...@gmail.comwrote: On Thu, Apr 16, 2009 at 11:48 AM, Michael Abato maeng...@gmail.comwrote: Even if the stream of bytes has no semantic meaning without the .proto, its format is still protobuf binary, so the MIME type makes some sense even if it is not sufficient. Did this discussion ever continue past this single thread? The only other thread I've noticed that matches on the term mime type doesn't really go into a great depth on the topic, so I can only assume no. That said, if I'm mistaken and this conversation has long since taken place and a determination made my apologies in advance for reopening a closed discussion. With the above disclaimer in place, might I make a suggestion to use the widely accepted (and for that matter, recommended) [category]/[type+serializationFormat] format where -- in the case of protocol buffers might look something like application/foo+protobuf where foo represents .proto for a given object? (e.g. application/atom+xml where atom represents the type and xml the serialization format) Putting a ref to the appropriate .proto in the HTTP headers REST-style seems sensible - loosely similar to declaring a schema or dtd on an XML file: From the standpoint of HTTP this makes a lot of sense: You can certainly specify to the .proto of a given type via an X- response header. But when it comes to anything /other/ than HTTP you're left to your own devices as to how to go about specifying the .proto type which, to me anyway, is just begging for fragmentation issues between transportation protocols. Of course, there is one obvious problem with the above and that is the dynamic nature of types compared to the very static, and slow moving process of requesting/registering/receiving an official IANA registered mime-type. But this is only a problem if you consider gaining an official IANA mime-type pertinent to the usage of the given mime-type string within your applications. If this is not something that you see as a barrier for adoption, then the one obvious approach to dealing with things like namespace clashes is to adopt a solution that has worked well for other dynamically driven spaces where name clashes are inevitable, that of using the tld.domain.classpath.type format adopted by the Java community to ensure that my application/foo+protobuf and your application/foo+protobuf can easily co-exist by simply using application/com.mydomain.foo+protobuf and application/com.yourdomain.foo+protobuf Thoughts/comments/criticism/suggestions? -- /M:D M. David Peterson Co-Founder Chief Architect, 3rdUrban, LLC Email: m.da...@3rdandurban.com | m.da...@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://broadcast.oreilly.com/m-david-peterson/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: missing parseFrom(...) variants in generate Java code; and how to build your own parseFrom() equivalent
On Tue, Aug 18, 2009 at 6:55 PM, Oliver Jowett oliver.jow...@gmail.comwrote:
Hi
Using 2.2.0, the compiler doesn't seem to be generating Java code for
the parseFrom(byte[],int,int) and
parseFrom(byte[],int,int,ExtensionRegistryLite) static methods.
Did it ever generate those methods? I don't remember if it did, but I
definitely don't remember removing them.
Is this deliberate, or just an oversight?
An oversight. Although the proliferation of generated parse helpers worries
me.
Also, it seems a bit awkward for a user of the generated code to
reimplement something equivalent to the parseFrom() variants. For
example, to parse a message from a flat array using a Message.Builder
determined at runtime, with the same semantics as parseFrom(), I have to
do something like this:
try {
message = builder.mergeFrom(array, offset, length).build();
} catch (UninitializedMessageException e) {
throw e.asInvalidProtocolBufferException();
}
The try-to-build-and-catch-and-rethrow is a bit horrible. Is there a
better way to do this?
I suppose we could introduce a (public) variant of build() for this.
Arguably your code should look like:
message = builder.mergeFrom(array, offset, length).buildPartial();
if (!message.isInitialized()) {
throw new InvalidProtocolBufferException(...);
}
It's a little bit nicer than the try/catch...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: Additional language
I get the error in Chrome, Firefox, and even IE (all on Windows), so I don't think the problem can be blamed on Chrome lacking root certificates. On Wed, Aug 19, 2009 at 9:03 AM, opticron nyphb...@gmail.com wrote: What certificate authorities would be acceptable for this purpose? I see that Chrome has root certs for only verisign and thawte, but that's still in beta and can hardly be considered a realistic sampling. The Mozilla project has root certs for MANY more than that. On Aug 19, 2:41 am, Marc Gravell marc.grav...@gmail.com wrote: The problem is the root certificate (CA Cert Signing Authority) - it certainly isn't in my trusted set of root certificates... On Aug 19, 3:50 am, opticron nyphb...@gmail.com wrote: It is a CACert certificate that is valid until May of 2010. On Aug 18, 7:46 pm, Kenton Varda ken...@google.com wrote: I'd like to add this to the list, but I noticed that the wiki page is an HTTPS link to a site with an invalid SSL certificate. I tried to change the protocol to just HTTP but the site automatically redirects to HTTPS. Modern browsers complain very loudly about this, and I feel weird posting a link that's going to display a big red security warning. Can you maybe fix your server to allow regular HTTP connections? On Tue, Aug 18, 2009 at 5:25 AM, opticron nyphb...@gmail.com wrote: I have spent some time developing a protocol buffer compiler in the D language. The wiki page is located at https://256.makerslocal.org/ wiki/index.php/ProtocolBuffer and the SVN repository that contains the compiler is located at http://opticron.no-ip.org/svn/branches/ PBCompiler. Please, note that you'll actually have to check out the branch, since the backend library it uses is in a svn:externals reference to a different location in the same repository. The compiler itself needs some work, but the generated code seems to generate and parse byte strings correctly. Please add my project to your third party compilers page. Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
(Java) Message.Builder build()/clear()
Hello, In 2.1, one could build() multiple objects in sequence, with the same builder object, by clear()ing it repeatedly. In 2.2, attempting this throws an exception -- from what I can tell a builder can only be used to create a single PB object. What's the rationale behind this decision? Cheers, -pwr --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: (Java) Message.Builder build()/clear()
On Aug 20, 1:09 am, Kenton Varda ken...@google.com wrote: On Wed, Aug 19, 2009 at 3:00 PM, pwr daniel.pa...@gmail.com wrote: In 2.1, one could build() multiple objects in sequence, with the same builder object, by clear()ing it repeatedly. No, you couldn't, at least according to the docs. Wll, you could. Or I found myself into a few lucky corner cases :). As the docs say, once you call build(), the builder is no longer usable. I have to admit I didn't read the docs that thoroughly. They do say so. The fact that it seemed to work with 2.1.0 and earlier was a mistake, and officially allowing this behavior would limit our ability to implement certain features and optimizations in the future. In particular there was an optimization involving putting builders on a freelist which seemed to improve performance on Android -- though this was removed just before the 2.2.0 release due to other problems. Sorry for the inconvenience. However, note that there is very little to gain by reusing a single builder object in this way, since the object is very small (just a pointer). Allocating a new builder for every iteration should not significantly harm performance. Noted. Thanks for the reply, -pwr --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: missing parseFrom(...) variants in generate Java code; and how to build your own parseFrom() equivalent
Kenton Varda wrote:
On Tue, Aug 18, 2009 at 6:55 PM, Oliver Jowett oliver.jow...@gmail.com
mailto:oliver.jow...@gmail.com wrote:
Hi
Using 2.2.0, the compiler doesn't seem to be generating Java code for
the parseFrom(byte[],int,int) and
parseFrom(byte[],int,int,ExtensionRegistryLite) static methods.
Did it ever generate those methods? I don't remember if it did, but I
definitely don't remember removing them.
I don't think so - I just tried to use them based on the documentation
saying there's a parseFrom() variant for each mergeFrom() and ran into
compile errors. I really did need to parse from a partial array there -
it was a section of a NIO buffer's backing array.
Arguably your code should look like:
message = builder.mergeFrom(array, offset, length).buildPartial();
if (!message.isInitialized()) {
throw new InvalidProtocolBufferException(...);
}
It's a little bit nicer than the try/catch...
Unfortunately, this doesn't give you the nice list of missing fields
that parseFrom() generates.
-O
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: missing parseFrom(...) variants in generate Java code; and how to build your own parseFrom() equivalent
Feel free to send a patch.
It would be nice if we could also move the meat of all the parseFrom methods
into AbstractMessageLite -- as protected static methods that take the
message default instance as the first parameter -- so that the generated
code can be as simple as possible. I'm worried that adding so many methods
is probably leading to binary bloat.
On Wed, Aug 19, 2009 at 5:18 PM, Oliver Jowett oliver.jow...@gmail.comwrote:
Kenton Varda wrote:
On Tue, Aug 18, 2009 at 6:55 PM, Oliver Jowett oliver.jow...@gmail.com
mailto:oliver.jow...@gmail.com wrote:
Hi
Using 2.2.0, the compiler doesn't seem to be generating Java code for
the parseFrom(byte[],int,int) and
parseFrom(byte[],int,int,ExtensionRegistryLite) static methods.
Did it ever generate those methods? I don't remember if it did, but I
definitely don't remember removing them.
I don't think so - I just tried to use them based on the documentation
saying there's a parseFrom() variant for each mergeFrom() and ran into
compile errors. I really did need to parse from a partial array there -
it was a section of a NIO buffer's backing array.
Arguably your code should look like:
message = builder.mergeFrom(array, offset, length).buildPartial();
if (!message.isInitialized()) {
throw new InvalidProtocolBufferException(...);
}
It's a little bit nicer than the try/catch...
Unfortunately, this doesn't give you the nice list of missing fields
that parseFrom() generates.
-O
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
